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1 INTRODUCTION 


1 . 1 PURPOSE 


This report describes the work done on the Mil ICD program 
and makes recommendations based on it. The final output of 
this study program is an Interface Control Document (ICD) 
for a Media Independent Interface which is a separate 
document . This report will provide explanations and 
rationale for the content of the ICD itself. A basic 
familiarity with the ISO OSI 7 layer model and the IEEE 802 
specifications is very helpful in understanding the contents,, 
of this report . *7 


1 . 2 ABBREVIATIONS 


ASN.l - Abstract Syntax Notation One 
CPU - Central Processing Unit 
DIS - Draft International Standard 
ICD - Interface Control Document 
ICI - Interface Control Information 

IEEE - Institute of Electrical Electronics Engineers 

ISO - Internation Standards Organization 

LAN - Local Area Network 

LLC - Logical Link Control 

MAC - Media Access Control 

Mil - Media Independent Interface 

OSI - Open Systems Interconnection 

PDU - Protocol Data Unit 

SDU - Service Data Unit 

SM - Station Management 

1 . 3 DEFINITIONS 

ICI - Interface Control Information - information 
transferred between adjacent layers to coordinate their 
joint operation 

PDU - Protocol Data Unit - a unit of data specified in a 
protocol and consisting of protocol information and possibly 
user data. 
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SDU - Service Data Unit - an amount of interface data whose 
identity is preserved from one end of a connection to the 
other . 


1 . 4 DOCUMENTS 


ANSI X3T9/84-100 Fiber Distributed Data Interface (FDDI) 

IEEE 802.1 (still draft) Network management 

IEEE 802.2 or ISO 8802/2 Logical Link Control (LLC) 

IEEE 802.3 or ISO 8802/3 Carrier Sense Media Access 


(CSMA/CD) 

IEEE 802.4 or ISO 8802/4 Token Bus 
IEEE 802.5 or ISO 8802/5 Token Ring 
IEEE 802.7 or ISO 8802/7 Slotted Ring 

ISO DIS 8824 Specification of Abstract Syntax Notation 
ISO DIS 8825 Basic Encoding for Abstract Syntax Notation 


ISO 7498 ISO OSI Basic Reference Model 
ISO 7498 DAD1 connectionless Data Transmission 
ISO DP 7498/4 Management Framework 
Sperry Report 2055-04 thru 2055-8 


1.5 Mil DEFINITION 

The Mil deals with the Data Link Layer. Layer 2 of the ISO 
7-Layer communication model. The IEEE 802 specifications 
divide the Data Link into two sub-layers; the Media Access 
Control (MAC) is the lower sub-layer and the Logical Link 
Control (LLC) is the higher sub-layer. The intent of the 
802 committee is to provide a single set of LLC functions 
that supports several different MAC and Physical layer 
implementations . 

The goal of the Mil project is to define an interface 
between these two sub-layers such that all media dependent 
functions of the Data Link reside in the MAC and all media 
independent functions reside in the LLC. This division of 
function results in an interface between the MAC and LLC 
sub-layers which has been called the Media Independent 
Interface or Mil. The Mil concept is illustrated in Figure 
1. The object of this division of function is to allow 
different media access and physical layers to be interfaced 
to the same upper layer implementation. The intent is to 
specify this interface to the level such that plug 
compatible interchangeable modules can be designed 
independently for both MACS and LLCs. In order to achieve 
this goal, the further complications added by the Station 
Management function must be considered. The Station 
Management entity must communicate with all layers and 
sub-layers of a given station as it is responsible for 
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insuring ” co-operation of all layers within the station and 
maintaining the health of the station as a whole. It 

therefore follows that the the interface must not only 
provide for MAC-LLC communication, but also MAC to Station 
Management (SMT) communication. Figure 2 shows the location 
of the entire Mil boundary. 

1.6 MU REQUIREMENTS AND GOALS 

The Mil requirements are as follows: 

1 . Support the functional independence between the 
interfacing entities, except to the extent of 
planned interaction through identified (and 
"controlled") primitives. This feature would make 
internal changes in the LLC, SM, or MAC transparent 
to each other. 

2. Support asynchronous operation of interfacing; 

entities. m 

3. Support the operation of high speed LANs, with bit 
rates on the order of 100 MBPS. Both Star*Bus and 
FDDI media bit rates are of this magnitude. 

4. Support multiples of each type entity, to 
facilitate bridge, router, and gateway design and 
multiple port networking. 

5. Support ease in reconfiguration, allow for 
replacing MAC or Physical Layer elements, without 
modification to the Mil or other interfacing 
elements . 

6. Allow for parallel processing and provide for event 
driven operations in order to support priority 

■— transmissions and transfer delay minimization. 

7~ Use industry accepted standards, especially ISO and 
IEEE 802. 

8. Provide complete interchangeability between MACs. 

9. Be expandable yet retain downwards compatibility. 



Figure 2 Mil BOUNDARY 
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2 ICD DESCRIPTION 

This section describes the contents of the final ICD 
specification. It is intended to aid in the understanding 
of the ICD by providing explanations for the features of the 
architecture and how they relate to the ICD specifications. 

2 . 1 LEVELS OF INTERFACE 

The Mil deals with three levels of interface: functional, 
electrical, and physical. The functional level deals with 
the primitives which are passed between entities and their 
meanings or interpretations. The design of this level is 
patterned after the IEEE and ISO specifications. The 
functions contained in these specifications and the logic 
contained therein are considered at this level. The 
electrical interface encompasses all aspects of the bu^ 
signals involved, including voltage level, pin assignments,' 
timing specifications , etc . The physical interface deals, 
with form and fit, module dimensions, connector, 
specifications, etc. Each of these levels of the interface 
will be discussed in detail in the subsequent sections. 

2 . 2 FUNCTIONAL INTERFACES 

The functional interface deals with the meaning of the data 
which crosses the Mil boundary. It is involved with what 
data crosses the boundary and how it is expressed and 
interpreted. The functional interface includes aspects of 
both semantics which has to do with meanings or relationship 
of meanings and syntax which is the form and order or the 
way in which language elements are connected. 

2.2.1 MAC-LLC INTERFACE 

The information which must traverse this interface is in the 
form ©-f data units which are to be sent out or data units 
which Save been received and require processing. This 
information must be passed in data buffers along with the 
control information associated with the transfer. Since 
data is being passed using buffers, a further requirement is 
to provide information to allow allocation and release of 
these buffers. Thus, when data has been passed and 
accepted, a handshake of some type is necessary to let the 
sender know that the buffer has been processed and can be 
released or reused. The IEEE specifications provide for the 
handshake in the case of data transfers from LLC to MAC, but 
not for data transfers from MAC to LLC, so the ICD has been 
expanded to provide that function. 
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The IEEE 'specifications provide for the handshake in the 
case of MA_DATA . request but not for MA_DATA . indication, so a 
primitive has been added to the ICD definition to handle 
this function. 

2.2. 1.1 LLC -MAC SERVICE PRIMITIVES 

The existing specifications describes primitives and 
respective parameters that are used to transfer information 
across the LLC/MAC interface. For a Type 1 LLC, IEEE 802 
defines three primitives: MA_DATA . request , 

MA_DATA. indication, and MA_DATA. confirm . The ICD uses the 
definitions for these primitives as given in the IEEE 
specification. A fourth primitive has been added to handle 
the handshaking requirement for the MA_DATA. indication which 
has been called MA_DATA.indication_ack. With this 
augmentation, two pairs of primitives are defined, one pair, 
for each direction of data flow. ' 

The MA_DATA. request and MA_DATA . confirm are use to transfer, 
data from LLC to MAC. The MA_DATA . request primitive is 
generated by the LLC entity whenever a m sdu (ie MAC service 
data unit) must be transferred to a peer LLC entity. Upon 
receiving this primitive the MAC entity appends all MAC 
specified fields including DA,SA, and any other fields that 
are unique to the particular media access method in use. 
The MA_DATA . confirm primitive is generated by the MAC entity 
in reply to a MA_DATA . request " . It is used to indicate the 
success or failure of the previous associated request. The 
LLC sub-layer is provided with sufficient information to 
associate this confirm with the appropriate request. 

The MA_DATA . indication and MA_DATA . indication_ack are used 
to transfer data from MAC to LLC. The MA_DATA . indication 
primitive is passed from the MAC entity to the LLC entity to 
indicate the arrival of a frame at the local MAC entity. 
Frames -are only reported if they are validly formatted and 
their destination address matches that of the local MAC 
entity.-- The MA_DATA . indication_ack is a non-IEEE primitive, 
necessary for proper handling of buffers, etc. The 
MA_DATA . indicat ion_ack primitive is generated by the LLC 
entity in acknowledgement of a MA_DATA. indication. It is 
used to indicate the success or failure of the previous 
associated .indication. The MAC sub-layer is provided with 
sufficient information to associate this primitive with the 
appropriate .indication. 
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2.2.2 MAC-SMT INTERFACE 

This section concentrates on the services provided by the 
Layer Management Entities (LME's) to the SMAP in order to 
manage that layer. The SMAP services available to users 
includes the services provided by the LMEs plus higher level 
services. Access to the layer management functions is via 
the Layer Management Interface ( LMI ) , which exists between 
the local systems management and the layer . The types of 
services provided across the LMI for the layer are the 
following: 

o The ability for systems management to read and 
write parameters within the layer 

o The ability for systems management to cause actions 
to occur within the layer. i 

o The ability for the layer to notify systems 
management of specific events which have been, 
detected by the layer. 


2 . 2 . 2 . 1 SYSTEM MANAGEMENT-LLC ( SMT-LLC ) SERVICE PRIMITIVES 
AND PARAMETERS 

This section discusses the primitives and their respective 
parameters used in Systems Management . These primitives are 
passed across the LMI for the MAC sub-layer in question. 
This is the more complex of the two interfaces into the MAC. 
The primitives which traverse this interface are defined in 
both IEEE 802.1 (System Management Spec) and IEEE 802.4. 
Unfortunately, the two definitions are inconsistent. The 

802.1 definition is used as it is more generally applicable 
set of primitives and offers more complete functionality. 
The primitives used for the Mil ICD are the following: 

eT LM_SET_VALUE . invoke 

o LM_SET_VALUE . reply 

0 LM_COMPARE_AND_SET_VALUE . invoke 

O LM_COMPARE_AND_SET_VALUE . reply 

o LM_GET_VALUE . invoke 

LM_GET_VALUE . reply 


o 
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o "LM_ACTION . invoke 
O LM_ACTION. reply 
o LM_EVENT. notify 
o LM_EVENT . reply 

Note that these primitives are arranged as command response 
pairs with the .reply as a required response for each 
.invoke or .notify. The reader will notice that the 
following two primitives constitute somewhat of an 
exception. 

LMJEVENT. notify 
LM_EVENT. reply 


For this set of primitives, the MAC initiates a .notify and, 
expects a .reply from the SM in response. In all other, 
cases, the SM issues the command primitive and the MAC is 
require to issue the .reply. This pair of primitives 
provides the means for the Station manager to set an event 
mask which allows the MAC to report events without a direct 
request. The reader will also note that the LM„EVENT . reply 
is not defined by IEEE. As was the case with the 
MA_DATA. indication, it was found that a response primitive 
for the LM_EVENT . nof ify was required to allow the proper 
disposition of message buffers being passed across the Mil. 

The IEEE 802.4 primitive functions which are implemented for 
the Mil ICD are mapped into the IEEE 802.1 primitives as 
follows : 


IEEE 802.4 


IEEE 802.1 


MA_INITTALIZE_PROTOCOL . request 
MA_INITIALIZE_PROTOCOL . confirm 
MA_SET_ VALUE . request 
MA_SET_VALUE . confirm 
MA_READ_ VALUE . request 
MA_READ_ VALUE . confirm 
MA_EVENT . indication 
M A_F AULT_RE PORT . indication 
M A_GR0U P_ ADDRE S S . request 
MA_GROUP_ ADDRESS . confirm 
MA_CDATA . request 
MA_CDATA . confirm 
MA_CDATA . indication 


LM_ACTION . invoke 
LM_ACTION . reply 
LM_SET_VALUE . invoke 
LM_SET_ VALUE . reply 
LM_GET_VALUE . invoke 
LM_GET_VALUE . reply 
LM_EVENT. notify 
LM_EVENT. notify 
LM_SET_VALUE . invoke 
LM_SET_VALUE . reply 
LM_ACTION . invoke 
LM_ACTION . reply 
LM_EVENT. notify 
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For detailed explanation of these primitives, the reader is 
refered to 
the ICD . 


2.2.3 INTERFACE CONTROL INFORMATION 

According to ISO, information transferred between entities 
in adjacent layers which co-ordinates their joint operation 
is known as Interface Control Information or ICI. The 
application data itself is the service data unit or SDU. 
The combined ICI and SDU is called an interface data unit or 
IDU. The ICI must be represented in some form which is 
understood by both layers. To accomplish this in a flexible 
way, the ICD specifies the use of a data transfer syntax 
encoding rules which are also ISO standards. 

2 . 2 . 3 . 1 DATA TRANSFER SYNTAX 

All data transferred across the Mil is described using 
Abstract Syntax Notation One (ASN.l) per ISO/DIS 8824. This 
International Standard specifies a notation for defining a 
syntax, defines a number of simple types, with their tags, 
and specifies a notation for referencing these types and for 
specifying values of these types. It further defines 
mechanisms for contructing new types from more basic types, 
a specifies a notation for defining such structured types 
and assigning them tags, and for specifying values of these 
types. It also defines character sets for use within ASN.l. 
This notation can be applied whenever it is necessary to 
define the abstract syntax of information. 

Use of this standard syntax in the Mil removes any logical 
inference by order from the interface. Information can be 
passed -in any order and its meaning is inferred by the 
structure of the message as it is decoded. This results in 
records" which are perhaps more lengthy than absolutely 
necessary, but offers the advantage of standardization and 
extensibility in the future. For example, a record 
containing an address contains information which indicates 
what kind of address it is as well as the address itself in 
a variable length format . A receiving entity such as the 
LLC could be modified to accept an extra long address 
without violating the standard or compromising compatibility 
with MAC'S using shorter addresses. 




Mil PINAL REPORT 
I CD DESCRIPTION 


Page 11 
21 July 1987 


2. 2. 3. 2 'ENCODING RULES 

Although ASN.l specifies a notation for defining a syntax, 
it does not specify how data is encoded. Therefore, basic 
encoding rules for information transfer are supplied by 
ISO/DIS 8825, Specification of Basic Encoding Rules for 
ASN.l. This standard defines a set of encoding rules that 
are applied to values of types defined using ASN.l which 
results in transfer syntax for such values. For a detailed 
definition of the transfer syntax, the reader is referred to 
the Mil I CD itself. 

2.2.4 PROTOCOL DATA UNITS 

2.2.5 DATA CHANNEL ARCHITECTURE 

Communications across the Mil boundary is accomplished with* 
predefined data channels. Data is passed over these*! - 
channels in the form of transactions with linked lists and; 
pointers. ¥ 

2 . 2 . 5 . 1 DATA CHANNEL DEFINITIONS 

2. 2. 5. 2 SYNCHRONIZATION 

Each entity has a single input data channel which consists 
of two globally addressable registers or memory locations. 
One location is designated as a semaphore. An entity 

wishing to send a message to the channel must perform a test 
and set operation on the semaphore location. If the test 
shows not busy, then the channel was free and the entity has 
won the right to use the channel. In this case, the entity 
may then write a pointer to his message in the second 
register which is reserved for that purpose. The entity 
receiving the message must have some way of detecting when 
the pointer has been written. This may be done in a number 
of ways depending on the system designer. One possible 
choice -is for the receiver to always write a guard word into 
the pointer prior to resetting the semaphore. Another would 
be for the act of writing to the pointer register to trigger 
an interrupt . The method used is immaterial to the sender 
as long the receiver can properly detect the occurance of 
the transmission. 

At initialization, the station manager must configure the 
MAC to know the location of the LLC and SMs semaphore bit 
and link list pointer. Likewise the SM configured the LLC 
to know the location of the MAC and SMs semaphore bit and 
link list pointer. Additional status locations are optional 
(and useful to display self test or BITE during power up). 
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2 . 2 . 5 . 3 -BUFFER MANAGEMENT 

In spite of their small size, maintaining memory resources 
for the ICIs can be difficult since so many are used so 
often. The IEEE standards do not address this issue, but do 
provide a reply to MA_Data. request even in a connectionless 
system. The response or reply for every request is not 
consistent throughout the IEEE standards and non-existent 
for the MA_DATA . indication . The lack of a response in this 
case presents a difficulty in returning memory blocks back 
to the system for reuse. Therefore the Mil ICD requires a 
reply for every request and each reply will overwrite the 
memory block which carried the request. In this way, the 
originator of the request receives his memory block back and 
may reuse it or return it to a system free pool. This 
suggests that the total amount of memory a entity requires 
for ICIs will not exceed the total number of outstanding, 
requests it expects to post. The PDU/SDU data (which i& 
pointed to by a ICI) could work the same way (i.e. a 
.indication is not acknowledged until the highest layer has 
copied it) or the receiving entity could copy it and' 
acknowledge it right away. Returning the block to the 
originator allows for retrys without requiring that an extra 
copy of the data be held for this purpose. This method is 
recommended for the Mil ICD so as to support both connection 
and connectionless, to support layer level resets, and ease 
complications once the data gets to upper layers which block 
and the records. The entities receive memory from the SM 
which passes to it a linked list of free fixed size memory 
segments. The SM supports alarms for low memory and 
requests for more memory. 

In the case of a reset to a layer, data may be lost or 
corrupted which is allowed per ISO OSI specs. The default 
for a layer which has been reset is to report the event to 
the Station Manager. At initialization, the MAC is given a 
linked -list of memory blocks to use for incoming data (from 
the madia) and a linked list of initialized memory blocks 
for outgoing data (to a remote station). Likewise, the SM 
will need to perform the same function for the upper layers, 
but this is transparent to the Mil. 

2.3 ELECTRICAL/ PHYSICAL INTERFACE 
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2.3.1 BUS STANDARDS 

There are several acceptable backplane bus standards 
available on the market today. Two of the more widely used 
designs are Multibus II and VMEbus. As would be expect, 
both of these designs have strong and weak points. Multibus 
II has built in parity and a large card size. However, it 
is a synchronous design which tends to be a speed 
disadvantage in an asynchronous system, and has less 
bandwidth. It also uses round robin arbitration, which 
ensures a more even distribution of bandwidth among users, 
but also limits the burst rate available to a single user. 

The VMEbus is an asynchronous design which tends to give it 
a speed advantage. It is a true multi-master bus, featuring 
priority driven arbitration. The theoretical bandwidth of 
40 Mbyte/sec is larger than that of the Multibus. However,* 
VMEbus uses a smaller card size and does not define any'! 
parity lines, although extra undefined lines might be. 
utilized for that purpose. « 

Either of these buses could be used to support the Mil. The 
selection of the bus standard is a system design issue which 
impacts performance and design tradeoffs. For example, use 
of Multibus II bus would require a larger buffer for the 
media (100 Mbit/sec) because of its relatively low 
bandwidth. On the other hand, use of Multibus II would 
prevent the MAC from monopolizing bus bandwidth because of 
its round robin arbitration scheme. 

In order to provide a complete Mil a electrical interface 
must be established. To support further discussion, the 
VMEbus has been selected as a baseline for the ICD. 
However, it should be noted that either candidate could be 
selected. In addition, as little reliance on VME 
characteristics as possible has been incorporated into the 
ICD in-order to facilitate adoption of another bus standard 
at a later date. 

2.3.2 IMPLEMENTATION OPTIONS 

2.3.2. 1 PHYSICAL PARTITIONING OF FUNCTIONS 

The Mil boundary is artificially based on IEEE 802 
specifications and the definitions of the primitives. 
However, the selection of a physical boundary between 
functions is more of a systems issue than an Mil 
requirement . The decision on where to physically locate 
functions has great impact on the power, weight, size, and 
speed factors of the implementation. The ICD does not 
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dictate "the physical partitioning of functions, but leaves 
these performance related decisions up to the system 
designer. It is possible for MAC functions to reside 
totally in a separate physical module or modules than the 
upper layers, but this is not a requirement. In the case of 
total physical separation at the Mil boundary, the MAC would 
send ASN messages over the VME bus. Alternatively, messages 
sent over VME could be proprietary as long as another module 
could convert them to ASN and retransmit them over the VME 
to himself. In this way, it is possible to make tradeoffs 
between hardware complexity and performance all within the 
confines of the ICD specifications. However, it should be 
noted that the Mil separation does introduce some 
inefficiencies that are unavoidable. 

2. 3. 2. 2 SIMPLE BIU OPTION 

The simplest implementation option is to use a single' 
general purpose processor. This option offers the lowest, 
cost at the expense of performance. The majority of the MAC, 
would be implemented using micro-controller technology in 
order to achieve the speeds necessary for handling the lower 
level functions. The upper layers, including the LLC would 
be implemented with software running on the general purpose 
processor. In order to achieve a minimal hardware 
implementation, the higher level MAC functions of 
interfacing to the SM and the LLC could actually be handled 
with software on the same processor which runs the upper 
layers . This is the approach that was actually used on the 
demonstration system. In order to conform with the Mil ICD, 
communications across the Mil would be handled over the VME 
bus, even though the elements communicating are running on 
the same processor. In order to achieve plug compatibility, 
the MAC software could be contained in a separate physical 
ROM which would plug into the processor card. 
Communications between the lower level MAC functions and the 
upper -layer MAC functions would be handled over the VME bus 
as welSI but would be permitted to use a much simpler 
language -than required for the Mil. This implementation 
option is illustrated in Figure 3. 

2. 3. 2. 3 MEDIUM SPEED BIU OPTION 

This option offers a compromise between cost and 
performance. Multiple general purpose processors are used 
to implement different layers, but all communications takes 
place over a single VME bus. This option is illustrated in 
Figure 4. All MAC functions are physically located on a 
module physically separate from upper layers. Again, lower 
level MAC functions would be implemented with high-speed 
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micro-controller technology. Upper level MAC functions run 
on their own general purpose processor. However, maximum 
performance would not be achieved with this design because 

all data transfers from the LAN interface to the common 

memory would be performed on the VME bus, tying up 

considerable bus bandwidth and limiting maximum transfer 
speeds. 

2. 3. 2. 4 HIGH SPEED BIU OPTION 

The highest speed operation would be obtained with this 
option. As with the medium performance option, multiple 
general purpose processors are used to implement different 
layers. However, this option would use a VMX bus for 

high-speed data transfers from the LAN interface to common 
memory. This design frees the VME bus for other activity, 
resulting in excellent performance. This option i 
illustrated in Figure 5. 

3 DEMONSTRATION SYSTEM 

This section describes the demonstration system which was 
built in support of the Mil development. The demonstration 
provided a testbed and proving ground for concepts and ideas 
being incorporated into the ICD. 

3 . 1 DEMONSTRATION GOALS 

3.2 SYSTEM DESCRIPTION 

The demonstration system was based on existing BIU hardware 
which was developed under the FODS and NOS contracts. 
Although this hardware was not designed with the Mil 
requirements in mind, it was adequate to provide the 
hardware platform for the proof-of-concept work that was 
required by the ICD project. The BIU consists primarily of 
an optical interface, a 68000 series processor with DMA, and 
RS-232- type interfaces. It also includes a high speed 
parallel - interface which was not used for the Mil 
demonstration. New software was written for the BIU 
processor which tested and demonstrated the Mil concepts and 
designs. 

Since a primary goal of the Mil is to allow different MAC 
protocols to interface to a common LLC design, two different 
MAC implementations were developed for the demonstration. 
Both MAC'S used the same hardware, but different software 
was used to implement a Star*Bus protocol and a token 
passing bus protocol. Since both implementations were 
interfaced to the same upper layer design, a much stronger 
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demonstration of the Mil design resulted. 

3 . 3 INTERFACE IMPLEMENTATION 

3.3.1 PRIMITIVES 

3.3.2 BUFFER MANAGEMENT 

A key element of a communication design is the handling of 
buffers. The demonstration utilized two basic buffer types 
for different purposes. Buffers for the data packets 
themselves (SDU/PDU) were pre-allocated during system 
initialization. These buffers are of a fixed size large 
enough to accomodate the maximum size data packet that the 
bus hardware can handle. These buffers are linked into a 
free list. Whenever either the MAC or LLC needs a data 
buffer, it is obtained from this list by a common system, 
service routine. When the buffer is no longer needed, it is- 
returned to the free list, again by a call to a system 
defined service routine. The buffer includes in its header, 
a pointer and byte count which defines the location of • the 
actual data within the buffer. The header also includes a 
link which is used to point to the next free buffer in the 
free list. 

Numerous other small buffers are used in the system for 
passing ICI across the interface. These buffers are 

obtained via a service call to the memory allocate routine. 
Generally, only enough memory is allocated to hold the 
expected message. When these buffers are no longer needed, 
they are returned to the free memory pool via a system call. 

In the demonstration system, these service calls are part of 
the interface definition. To avoid unnecessary dependencies 
on operating system implementation, we propose that the task 
of buffer management and memory allocation be handled by the 
station- manager via standard primitives defined for that 
purpose]'. These primitives are defined in the final Mil ICD. 

3.3.3 OPERATING SYSTEM 

The major thrust of the Mil ICD project was to demonstrate 
the separability of the LLC and MAC functions. While the 
use of separate physical processors for these functions may 
be necessary to achieve high rates of throughput, it is 
possible to demonstrate the separability of function 
required for the Mil demonstration with other means. The 
use of separate software tasks running under a real-time 
multi-tasking operating system effectively accomplishes the 
same thing with less hardware. The purpose of a 
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multi-tasking OS is to allow many independent tasks to run 
concurrently on one processor. Effectively, the OS 
transforms one physical processor into multiple logical 
processors. The technology for doing this is well developed 
and widely known. This technique was employed for the Mil 
demonstration to show the separation of media dependent and 
media independent functions. 

The operating system services play an important role in the 
demonstration system. Operating system calls are used to 
allocate and deallocate memory for the various buffers. In 
addition, the interprocess communications provisions of the 
OS are used for communications across the Mil. These 
functions are provided by calls to the signal and wait 
system service routines. In the final ICD, these 
communications are replaced by the use of the semaphore and 
pointer locations defined for each entity. These transfers, 
are expected to occur over the VME bus. The rigorous use of-; 
OS services for this function provides the same level of 
separation as is provided in the final ICD. , 

3.3.4 ASN . 1 SYNTAX 

The demonstration system used ASN.l syntax and encoding 
rules for data transfers across the Mil as described in 
Section 2. The resultant transfer language is given in the 
SOFTWARE USER MANUAL in Appendix B. 

3.4 DEMONSTRATION SYSTEM DETAILED DESCRIPTION 

3.4.1 COMPONENT IMPLEMENTATION 

3 . 4 . 1 . 1 TOKEN MAC 

The design of the Token Bus MAC was purposely kept very 
simple for this demonstration. Since it is implemented with 
software to run on the Star*Bus hardware, performance is 
inherently limited and no attempt was made to optimize the 
design,” The operation of the Token Bus MAC is very loosely 
patterned after IEEE 802 . 3 , but many of the advanced 
features that would normally be designed into firmware were 
not incorporated. Priority service and ring entry and exit 
algorithms are not provided. Token recovery is performed 
via a simple watchdog timer that detects when the token has 
apparently been lost. Initialization of the token is 
performed by a manually activated system management command. 
Unsuccessful attempts to pass the token are detected using 
the acknowledge supplied by the FODS hardware and retrys are 
attempted in this case. The Token Bus MAC acknowledges the 
existence and manipulates the variables in the list below, 
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although 'not all of them have any real function in the 
demonstration system. 



Variable list, token MAC 

3 . 4 . 1 . 1 . 1 MAC PROCESS 

The Token MAC process basically builds and maintains queues 
of commands and data packets. It processes requests and 
commands received from the LLC and station manager and 
builds -"a queue of data packets for the interrupt servicer to 
transmit.- SM commands are processed by taking appropriate 
actions and/or building response primitives and sending them 
back. This process also receives packets from the interrupt 
service routines and queues them to the LLC. 

3 . 4 . 1 . 1 . 2 INTERRUPT SERVICERS 

The interrupt servicers are those routines which deal 
directly with the hardware. These routines manage the token 
and perform DMA transfers of data packets from data buffers 
to the transmitter and from the receiver decoder to data 
buffers. Data buffers are passed to and from the MAC 
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process via special queues. Also, these routines collect 
statistic relating to the passing of tokens. 

3.4. 1.2 STAR* BUS MAC 

The Star* Bus MAC uses a proprietary bus protocol developed 
for space applications under another project. Most of the 
protocol is handled in specially designed micro-coded 
hardware, so that services performed by the software are 
minimal. The Star*Bus MAC recognizes different variables 
than the Token MAC, which are listed below. 

VARIABLE NAME 
MAC_TYPE 
TS 

SLOT_TIME 
INTER_FRAME_GAP 
ATTEMPT_LIMIT 
BACK_OFF_LIMIT 
JAM_SIZE 
MAX_FRAME_SIZE 
MIN_FRAME_SIZE 
ADDRESS_SIZE 
EVENT_ENABLE_MASK 
MA_GROUP_ADDRESS 
MA_GROUP_ADDRESS_ALL 


Variable list , STAR MAC 

3 . 4 . 1 . 2 . 1 MAC PROCESS 

The Star*Bus MAC process performs basically the same 
functions as the Token MAC. However, the Star* Bus MAC must 
initiate the first transmission after the transmit queue has 
been allowed to empty since there is no token being passed 
to cause data transmissions to begin. Also, the Star*Bus 
MAC reeognizes and processes variables which have meaning to 
its own protocol 

3 . 4 . 1 . 2 . 2 INTERRUPT SERVICERS 

The Star*Bus MAC interrupt servicers perform basically the 
same functions as those of the Token MAC. However, there is 
no token to manage which is the major difference. 




Mil FINAL REPORT 
DEMONSTRATION SYSTEM 


Page 23 
21 July 1987 


3 . 4 . 1 . 3 'LLC 

As discussed in a previous section, development of a fully 
functional LLC was found unnecessary to adequately 
demonstrate the Mil design. Therefore, the demonstration 
LLC component includes only the basic functions of sending 
and receiving packets. The special LLC test functions were 
not required for the demonstration. Basically, the LLC must 
deal with only the four primitives defined for the MAC-LLC 
interface. This section of software also included test 
functions of packet generation and analysis. 

3 . 4 . 1 . 3 . 1 SEND 

This process is responsible for handling all data packets to 
be transmitted by the MAC, whether they are generated 
internally or entered from the console. Packets may be g 
generated in a number of ways and from various sources which- 
are described in more detail in the Operators Manual in the 
appendix. For each packet sent, this process builds a, 
request primitive and passes it to the MAC. It also handles 
the reply primitive which is passed back as a result of each 
request and disposes of the associated data buffer as is 
appropriate. This process also keeps statistics on the 
number of packets which have been originated and 
successfully sent to the MAC for transmission. 

3.4. 1.3.2 RECEIVE 

The receive process collects and disposes of packets 
received from other stations. It accepts MA_DATA . indication 
primitives from the MAC and generates MA_DATA. indication_ack 
for each one received, thus returning the data buffer to the 
sender(MAC). It also collects statistics on received 
packets . 

3 . 4 . 1 . 4 STATION MANAGEMENT 

A formal station manager was outside of the requirements for 
the ICD program and therefore was not include in the 
demonstration. In essence, the test operator performs the 
function of station manager in the demonstration system. 
This portion of the system provides the operator with a 
control and test interface into each BIU via an RS-232 
interface. The software translates operator input commands 
into the appropriate SM primitives to perform the desired 
actions. Statistics information gathered throughout the 
system are also collected and displayed per operator 
commands . 
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3 . 4 . 1 . 4 . 1 GOMMAND INTERPRETER 

This process performs all work associated with handling 
input from the operator. This includes buffering of command 
lines. editing functions, parsing of the command into 
keywords and associated parameters, and calling of 
appropriate handlers to perform or initiate requested 
functions. The command interpreter accepts user input 

commands, translates them into SM primitives which are sent 
to the MAC. It also accepts test commands and activates the 
requested test functions, for example the sending of packets 
or activation of a display mode. 

3. 4. 1.4. 2 DISPLAY 

This process provides display of packet contents on the CRT. 

It is required because the operating system provides only^A 
blocking I/O which stops the process requesting the I/0'~W 
until the request has been satisfied. Therefore, this I- 
process is used to perform the display function so that^ 
other processes may continue to execute while the output 
proceeds . 

3.4. 1.4.3 STATISTICS 

This process drives the real time statistics display for the 
system when activated. It also serves as a collection point 
for SM events reported by the MAC process. The statistics 
display is updated periodically per a system alarm timer. 

3 . 5 DEMONSTRATION TESTING 

The Test Set Up which was used to perform the ICD Mil 
demonstration consists of 3 BIU's communicating over a fiber 
optic link (Star*Bus). Each of the BIU's interfaces to a 
CRT terminal via an RS-232. The terminal provides the 

operator with test, control, and station management 

functions for the interfacing BIU. A block diagram of the 
test setup is shown in Figure 6. 
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User Console Commands 

The following are valid commands which the operator may 
enter from the console and which result in the described 
activity or functions. Lists of valid variables which may 
be manipulated for the two MAC'S are found in the Token 
Bus/Star*Bus Medium Access Control Software User Manual. 

SET varname - examine variable and allow change 

DIS_VAR varname - display value of single variable 

TEST varname 1 .test ,varname2, const - perform comparison test 
specified between two variables and set the first variable 
equal to a constant if the test is satisfied. The parameter 
"test" may take on the following values: 

< - test for varnamel less than varname2 

> - test for varnamel greater than varname2 
= - test for varnamel equal to varname2 

< > - test for varnamel not equal to varname2 

<= - test for varnamel less than or equal to 
varname2 

>= - test for varnamel greater than or equal to 
varname2 

The comparison is an atomic test performed using the compare 
and set Station Management primitive. No action other than 
display of an error message will be taken if either variable 
is not a valid MAC variable. However, type-checking will 
only be performed by the MAC when the primitive is 
processed. 

CTEST varnamel , test , constant - perform comparison test 
specified between a variable and a constant and set the 
variable equal to the constant if the test is satisfied. 

The parameter "test" may take on the following values: 

< - test for varnamel less than constant 

> - test for varnamel greater than constant 
= - test for varnamel equal to constant 
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*< > .- test for varnamel not equal to constant 

<= - test for varnamel less than or equal to 
constant 

>= - test for varnamel greater than or equal to 
constant 

The comparison is an atomic test performed using the compare 
and set Station Management primitive. No action other than 
display of an error message will be taken if the variable is 
not a valid MAC variable. However, type-checking of the 
variable and constant will only be performed by the MAC when 
the primitive is processed. 

DIS_MAC - display all MAC variables 

SENDS [ address] t , pattern] - send single packets to station 
address starting with pattern as random seed for packet 
generator. Once entered, the routine accepts: 

s - send next packet, rotating pattern 

r - resend last packet 

x - quit 

c - send console defined packet 

Both parameters are optional and will default to previously 
used address and pattern. 

SENDC [t ][,] [p] [,] [address list] - send packets continuously 
t = time between packets 

« p = (r)otating or (f)ixed pattern or (c)onsole 
" entered packet or fixed (q)ueue of rotating 
packets. 

address list = list of up to 16 destination 
addresses separated by commas. 


KILL_SEND - cancel the continuous sending of packets 
previously activated via the SENDC command. 

KILL_STATS - cancel the display of real-time statistics. 
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CONSOLE taddr] - accept and send ASCII text from the console 
and display received packets on console in ASCII 

DEF_PACKET - enter a packet from the keyboard in HEX for 
subsequent transmission by another command. 

DIS_STATS - display static statistics 

RESET - re-initialize variables in this station 

DIS_RT - display realtime statistics in the realtime window. 

FREEZE - freeze MAC activity 

UNFREEZE - resume normal MAC activity 

ENTER_RING - activate the ring by passing a token frame to 
the next station. This command will also activate the 
watchdog token timer so that this station will generate a 
new token if it is dropped. 

EXIT_RING - consume the token by refusing to pass the next 
token received and deactivate the watchdog token timer. 

DIS_GA - display group address table 

GRP_ADDR [ - ] addr - modify group address table by adding or 
deleting the specified address. The minus sign causes the 
address to be deleted from the table if it already exists. 

If table is full or address is already defined or attempt is 
made to delete address not previously defined, then an 
appropriate error message is displayed. 

CLR_GA - clear the entire group address table. 

CLR_STATS - clear all statistical counters. 

DIS_PAGKET x - display packet in HEX format on the CRT. 
Parameter -x may take on values of: 

r = last received packet 

s = last sent packet 
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1 PURPOSE ' 

The purpose of this document is to give interface 
descriptions for implementation of the Media Access 
Controller (MAC) and software which is to interface to it. 


2 SCOPE 

This document contains general descriptions of interface 
syntax, commands and variables and responses the mac will 
have to those commands and variables. 


2 . 1 GENERAL 

Each section of this document contains a subsection which 
describes with text the general theory of operation for its 
respective component . 

For additional information see the ISO DIS 8824 document 
Specification of Abstract Syntax Notation One (ASN.l). 
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3 ARCHITECTURE 

The Media Access Controller (MAC) is the device which 
manages the actual transfer of data on a local area network 
(LAN). It interfaces to the physical layer (i.e. the 
hardware) and manages it in such a way as to provide a means 
by which it can share the communication resources the 
hardware provides. 

The MAC task has two interfaces to the outside world; the 
Logical Link Control (LLC), and the Station Manager (SM). 

The LLC is the source and sink of data to the MAC. It 
requests the MAC to perform a service of shipping data to an 
address. In addition the MAC will indicate to the LLC when 
another remote LLC has passed data to it. 

The instructions to the MAC are queued by the LLC and a 
message is sent to the MAC so it will be awakened by the OS. 
The MAC de-queues it and puts it into a message queue for 
the MACs interrupt routine. The interrupt routines take it 
from there. The MAC can get a message from the interrupt 
routines which indicate to the MAC that data has arrived 
from another remote MAC. The MAC queues a message to the 
LLC to awaken it and indicate that a message has arrived and 
where it is . 

The Station Manager interfaces in the same way as the LLC 
but its primitives are move extensive. It has the ability 
to set variables in the MAC, read its status, reset it, and 
perform all the necessary functions to manage the media. 

For each request passed to the MAC from the LLC or SM there 
is a confirm. When the MAC initiates a request, event, or 
indication, it expects a confirm. These confirms allow the 
requestors to deallocate the original message. 

Each section gives further details on the method by which 
the MAC commands operate. 
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4 INTERFACES 

4 . 1 LLC 

4.1.1 COMMANDS - 

The LLC Interface supports MA_DATA request and confirms and 
MA_DATA indication and indi_acks. Details of these commands 
are described in the IEEE 802.3, IEEE 802.4 and IEEE 802.2 
documents. A brief explanation follows; 


MA_DATA . REQUEST 

{ DESTINATION_ADDRESS , M_SDU, DESIRED_QUALITY } 

This command comes from the LLC to the MAC and represents a 
request to ship the data pointed to by the M_SDU to the 
station at address DESTINATION_ADDRESS using a level of 
quality of DESIRED_QUALITY . The MAC is expected to respond 
with the following command; 

MA_DATA . CONFIRMATION 
{ QUALITY, STATUS } 

This command from the MAC to the LLC will indicate to the 
LLC that the data previously requested to be shipped has 
been sent . The LLC knows what data was sent because the 
MAJDATA . CONFIRMATION message is returned to the LLC by 
overwriting the original MA_DATA. REQUEST message. 


MA_DATA . INDICATION 

{ DESTINATION_ADDRESS , SOURCE_ ADDRESS , 

M_SDU , QUALITY > 

This command from the MAC to the LLC will indicate to the 
LLC that- data located at pointer M_SDU from the station 
SOURCE_ADDRESS was sent to DESTINATION_ADDRESS (needed to 
identify 'when a group address is used) with a QUALITY of 
service. The MAC expects the LLC to overwrite the 
MA_DATA . INDICATION with the MA_DATA . INDI_ACK thus allowing 
it to release the message buffer. 


MA_DATA . INDI_ACK 
{ STATUS } 

This command from the LLC to the MAC will indicate to the 
MAC that the LLC has no more use for the indicate message 
buffer . 
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4.1.2 SYNTAX - 


The LLC communicates to the MAC across the Mil. The syntax 
of such communication is described in the Software Design 
Document according to Abstract Syntax Notation One or ASN.l 
(ISO DIS 8824). The information described is encoded to the 
basic coding rules as found in ASN.l (ISO DIS 8825). Some 
sample records follow the syntax notations in the station 
management interface section. 
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MESSAGE_RECORD 
j MA_Dat a_ request 
MA_Dat o_conf i rm 
MA_Dat a_ i nd i cate [2] 
MA_lndi_ack [3] 


ma_request_type j 

ma_conf i rm_type | 

ma_ i nd i cate-type | 
ma_ i nd i_ack_type } 


:= [PRIVATE 0] CHOICE 

[e] 

[i] 


ma_reques t_type : := SET 
) dest i not i on_address 


M_SDU 

reques t ed_Se r_c lass 
f rame_cont ro I 
st ream 
I i nk_ I i st 
token_c I ass 


[0] net_add ress_type 

[1] M_SDU_t y pe 

[2] req_ser_type 

[3] f rame_con_type 

[4] stream„type 

[5] I i nk_ I i st_type 

[6] token_c I ass_type 


(opt i ona I ) 
(opt i ona I ) 
(opt i ona I ) 
(opt i ona I ) 


— Multiple request_i nf o’ s are allowed for FDD I only. 

— token_class allowed for FDDI only and has a default. 


ma_ i nd i cat e-type : := SET 

} dest i not i on_add ress [0] net_address_type 
sou rce_add ress [l] net_address_type 

M_SDU [2] M_SDU_type 

recept i on_s t atus [3] rec_status (optional) 
request ed_Se r_c I ass [4] req_ser_type (optional) 
f rame_cont rol [5] f rome_con_type (optional) 

I 

— The optional parameters have a default value. 


ma_conf i rm_type : := 


| t ransm i t_s tatus 

[e] 

t ron_status 


prov i ded_.se r_c lass 

[i] 

prov i ded_se retype 

(opt i ona 1 ) 

numbe r_of _sdu_ 1 inks 

[2] 

numbe r_of _sdu (opt 

i ona 1 ) 


} 


ma_ i nd i_acfc_type : := SET 

J indi_status [0] integer — 1 * good 0= not accepted 

i 

net_address_type : := CHOICE 
| net_add VALUE__INTEGER_1 { 

M_SDU_type : := SET 
} SDU.PTR [0] 

SDU.SIZE [1] 

buff_num [2] 


ADDRESS. 
INTEGER, 
INTEGER } 
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20 J 

req_se retype* : := 

.SET 



| priority 

[0] 

INTEGER, 

(opt i ona I ) 

response 

[1] 

INTEGER, 

(opt i ona 1 ) — ack = 

qua 1 i ty_of_se r 

[2] 

INTEGER 

j (opt i ona 1 ) 
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prov i ded_se retype : := 
\ priority 10] 

response [1] 

qua I i ty_of _ser [2] 


SET 

INTEGER, 

INTEGER, 

INTEGER 


(opt i ona I ) 

( opt i ono I ) — ack = 
(opt i ona I ) j 


i nd i _ac k_t y pe : SET 
\ indi_ack_ status ack_status j 


f rame_con_t ype : SET — TBD 
I ink_l ist_type : SET jj —TBD 


stream_type : := SET — TBD 

t oken_c I ass_t y pe : := SET — TBD 

rec_status : :» CHOICE 
} status [0] INTEGER — 1 = good \ 


tran_status CHOICE 
} status [0] INTEGER — 1 = good } 

numbe r_of _sdu : := CHOICE \\ — TBD 
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WHAT FOLLOWS IS WHAT IS ACTUALLY USED OUT OF THE ABOVE 
FOR A REOUEST (TO A 802.3 MAC): 

MESSAGE_RECORD : :* [PRIVATE 0] CHOICE 
[MA_Data_request [0] 

[dest i nat i on_oddress [0] 

[ net_add VA LUE_ I NT EG ER_ 1 

i 

M_SDU [ 1 ] 

} SDU_PTR [0] ADDRESS, — IROB 

i 

request ed_Ser_c I ass [2] 

[priority [0] INTEGER, (optional) — priority 

response [l] INTEGER, (optional) — ock = 1 

I 

I 

} 


Typical confirm of a previous response. 

MESSAGE_RECORD : ;* [PRIVATE 0] 

[ MA_Data_conf i rm [1] 

} t ransmi t_status [0] 

[status [0] INTEGER — 1 m good 

j 

provided_ser_closs [1] 

[priority [0] INTEGER, — priority 

\ 


I 
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A typical indicate message from the MAC to the LLC. 

MESSAG E_R ECORD : := [PRIVATE 0] 

} MA_Dat o_ i nd i cat e [2] 

J des t i nat i on_add ress [0] 

} net_add VALUE_INTEGER_1 | 
source_address [l] 

} net_add VALUE_INTEGER_1 j 
M_SDU [2] 

) SDU.PTR [0] ADDRESS — I ROB prt , 

recept i on_status [3] 

[ status [0] INTEGER — 1 = good 

\ 

requested_Ser_c I ass [4] 

J priority [0] INTEGER, — priority 

[ 

I 

I 


MESSAGE.R ECORD : := [PRIVATE 0] CHOICE 
J MA_Indi_ock [3] 

} indi_status [0] integer — t = ok 0= !ok. 
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ENCODING: 




e0 1 c 



MESSAGE.RECORD 

e0 1 o 



MA_Da ta_ request 

e0 06 




c0 02 

XX 

XX 

net_add INTEGER 

el 06 




c0 04 

XX 

XX 

xx xx SDU_PTR ADDRESS 

e2 08 




00 02 

XX 

XX 

priority INTEGER 

cl 02 

XX 

XX 

response INTEGER 


e0 0e 

MESSAGE_RECORD 

el 0c 

MA_Data_conf i rm 

e0 04 

C0 02 xx 

xx status INTEGER 

e0 04 

c0 02 xx 

xx pr i or i t y I NTEGER 


e0 22 



MESSAGE_RECORD 

e2 20 



MA_Da t a_ i nd i c a t e 

e0 04 



dest i not ion 

c0 02 

XX 

XX 

net_add INTEGER 

el 04 



source 

C0 02 

XX 

XX 

net_add INTEGER 

e2 06 




c0 04 

XX 

XX 

xx xx SDU_PTR ADDRESS 

e3 04 




c0 02 

XX 

XX 

status INTEGER 

e4 04 




c0 02 

XX 

XX 

priority INTEGER 

e0 08 “ 



MESSAGE_RECORD 

e3 06 “ 



MA_I nd i_ock 

c0 02 xx 

XX 


indi_status INTE( 
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4 . 2 STATION MANAGER COMMANDS 


4.2.1 COMMANDS - 

The Station manager sends invoke commands to the MAC and the 
MAC responds with a reply response. The pairs which follow 
are first station manager command followed by the MAC 
response . 

SM_MAC_LM_SET_VALUE . INVOKE 
SM_MAC_LM_SET_VALUE . REPLY 


SM_MAC_LM_GET_VALUE . INVOKE 
SM_MAC_LM_GET_VALUE . REPLY 


SM_MAC_LM_COMPARE_AND_SET_ VALUE . INVOKE 
SM_MAC_LM_COMPARE_AND_SET_VALUE . REPLY 


SM_MAC_ACTION_VALUE . INVOKE 
SM_MAC_ACTION_VALUE . REPLY 


The Station manager can set an event mask which allows the 
MAC to report events without a direct request. The MAC 
initiates a NOTIFY and expects a REPLY from the LLC in 
response . 


SM_MAC_EVENT_VALUE . NOTIFY 
SM_MAC_EVENT_ VALUE . REPLY 
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4.2.2 IEEE -802.3 COMMAND DESCRIPTIONS - 


SM_MAC_LM_SET_ VALUE . INVOKE 
{ PARAMETER_TYPE , ACCESS_CONTROL_INFO } 

The objective of the SM_MAC_LM_SET_VALUE . INVOKE command by 
the SM is to set a value in the MAC as defined by the 
parameter_type structure. This structure specifies both the 
variable to be set and the value to which it is set. 

SM_MAC_LM_SET_VALUE . REPLY 
{ STATUS } 

The objective of the reply by the MAC to the SM is to< 
indicate the success or failure of a previous 
SM_MAC_LM_SET_VALUE. INVOKE. The SM expects the MAC to 
overwrite the SM_MAC_LM_SET_VALUE . INVOKE with the, 
SM_MAC_LM_SET_VALUE . REPLY thus allowing the SM to release 
the message buffer. 


SM_MAC_LM_GET_VALUE . INVOKE 
{ PARAMETER_TYPE , ACCESS_CONTROL_INFO } 

The objective of the SM_MAC_LM_GET_VALUE . INVOKE command by 
the SM is to get a value in the MAC as defined by the 
parameter_type structure. This structure specifies the 
variable to be read. 

SM_MAC_LM_GET_ VALUE . REPLY 
{ PARAMETER_TYPE , STATUS } 

The objective of the reply by the MAC to the SM is to 
indicate - the success or failure of a previous 
SM_MAC_LM_GET_VALUE . INVOKE . The SM expects the MAC to 
overwrite the SM_MAC_LM_GET_VALUE . INVOKE with the 
SM_MAC_LM_GET_VALUE . REPLY thus allowing the SM to release 
the message buffer. 


SM_MAC_LM_COMPARE_AND_SET_ VALUE . INVOKE 
< PARAMETER_TYPE , OPERATION_COMMAND , 
ACCESS_CONTROL_INFO > 
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The Compare. and Set value command forces the MAC to do a 
comparison (of either a given constant or of a MAC variable) 
against a MAC variable. If the comparison is true then the 
MAC variable is over written. The PARAMETER_TYPE indicates 
the parameter to be over written and the value to use. The 
OPERATION_COMMAND structure specifies the comparison to do, 
and the constant or MAC variable to use in the comparison. 

SM_MAC_LM_COMPARE_AND_SET_VALUE . REPLY 

\ STATUS, RETURN_VAL > 


The objective of the reply by the MAC to the SM is to 
indicate the success or failure of a previous 
SM_MAC_LM_COMPARE_AND_SET_VALUE . INVOKE . The SM expects the 
MAC to overwrite the SM_MAC_LM_COMPARE_AND_SET_VALUE . INVOKE 
with the SM_MAC_LM_COMPARE_AND_SET_VALUE . REPLY thus allowing 
the SM to release the message buffer. 


SM_MAC_ACTION_VALUE . INVOKE 
{ PARAMETER_ID , ACCESS_CONTROL_INFO } 

The objective of the SM_MAC_ACTION_VALUE . INVOKE command by 
the SM is to force a MAC operation (i.e. reset, freeze) in 
the MAC as defined by the parameter_ID structure. This 
structure specifies the action to be performed. 

SM_MAC_ACTION_ VALUE . REPLY 
{ STATUS, ACT I ON_RE PORT } 

The objective of the reply by the MAC to the SM is to 
indicate the success or failure of a previous 
SM_MAC_ACTION_VALUE . INVOKE . The SM expects the MAC to 
overwrite the SM_MAC_ACTION_VALUE . INVOKE with the 
SM_MAC-ACTION_VALUE . REPLY thus allowing the SM to release 
the message buffer. 


MAC_SM_EVENT_VALUE . NOTIFY 
{ EVENT_ID } 

The objective of the MAC_SM_EVENT_VALUE . NOTIFY command by 
the MAC is to report a event which has occurred in the MAC 
as defined by the EVENT_ID structure. This structure 
specifies the Event and an integer. These events can be 
masked by setting the EVENT_MASK variable. 
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MAC_SM__EVENT_ VALUE . REPLY 
{ STATUS } 

The objective of the following reply by the SM to the MAC is 
to indicate the success or failure of a previous 
MAC_SM_EVENT_VALUE . NOTIFY . The MAC expects the SM to 
overwrite the MAC_SM_EVENT_VALUE . NOTIFY with the 
MAC_SM_EVENT_VALUE . REPLY thus allowing the MAC to release 
the message buffer. 
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READ_WR 1 T E_VALUE_TYPES : := CHOICE } 

[0] MAC_TYPE 

[1] TS 

[2] SLOT_TIME 

[3] I NT ER_FRAME_GAP 

[4] ATTEMPT_LIMIT 

[5] BACK_OF F_ L I M I T 

[6] JAM_SI ZE 

[7] MAX_ FRAME_S I Z E 

[8] M I N_FRAME_S I ZE 

[9] ADDRESS_SIZE 

[10] EVENT_ENABLE_MASK 

[11] MA_GROUP_ADDRESS 

[12] MA_GROUP_ ADDR ESS_A L L 
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TS ::= VA LUE.ADDRESS. 1 

This variable represents the address of this station. Since 
FODS has its address set in hardware this variable has no 
effect on MAC performance. 


SLOT.TIME : := VALUE_I NTEGER.1 

This variable represents the slot time of this station. This 
is the maximum time this station must wait on another 
station to respond to a transmit ion. The FODS knows this as 
T_Gap. Since FODS has T.Gap set in hardware this variable 
has no effect on MAC performance. 


EV ENT. ENAB L E.MASK : := EVENT. ENAB LE_B I T S 

EVENT.ENABLE.B ITS ::= BIT STRING 
| DUPLICATE. ADDRESS (2), 

FAULTY.TRANSMI TTER (3) , 

XMI T.QUEUE.THRESHOLD.EXCEEDED (4) , 

RECE 1 VE_QUEUE_THRESHOLD_EXCEEDED (5) , 
WATCH_DOG_T I MEOUT ( 6 ) , 

FROZEN (7), 

MAX.RETRY. ENCOUNTER ED ( 10) , 

BAD.MESSAGE.SENT (11) { 


— Where 1 is enabled 


The MAC will report events when discovered and the 
appropriate bit is set in the MASK above. These bits are 
inspected each time the event has occurred and the MAC task 
is active. The event is reported only once whenever the 
actual occurence is detected. 


ATTEMPT. LJWIT ::= VALUE. I NT EGER. 1 

This is the maximum number of times that a packet will be 
retransmitted when the acknowledgement indicates a bad 
t ransm i t t i on . Since this is a connectionless system this 
variable will not be used. 


MA.GROUP.ADDRESS : := VALUE.ADDRESS.1 

The MAC can respond to a group of group addresses. This is 
one of two methods for the Station Manager to tell the MAC 
which addresses are acceptable. This implementation will 
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support a total of 16 group addresses. A positive value in 
this command will set this address as part of the group 
addresses (unless there all used up) and a negative address 
will delete this address from the table. 


MA_GROUP_ADDRESS_AL L : := VAIUE_ADDRESS_1 6 

The MAC can respond to a group of group addresses. This is 
one of two methods for the Station Manager to tell the MAC 
which addresses ore acceptable. This implementation will 
support a total of 16 group addresses. This command will 
write or read all 16 addresses at once. Addresses which are 
not valid addresses should be set to a negative one. 
Therefore only positive addresses will be passed in with 
this command unless there a negative one (a null address). 


FREEZE_MAC : :» VALUE_I NTEGER_1 

This variable when set to one will freeze the MAC from 
taking any data from the local LLC. A negative one will 
unfreeze it and allow any queued messages to be processed. 
This will cause a burst effect and may cause loss of data 
due to the connectionless nature of the system and the 
limited buffer space. 

MAC_TYPE : 03h 

This variable is o reod only variable and indicates which 
version of MAC is responding. 

1 NT ER_ FRAME_GAP : VALUE_ I NT EG ER_1 

This is function cannot be changed with software in FODs and 
this variable will not have a effect on the performance 
of the MACr 


BACK_OFF_LIMIT : VALUE_INTEGER_1 

This is function cannot be changed with software in FODs and 
this variable will not have a effect on the performance 
of the MAC. 


JAM_S I ZE ::= VALUE_I NTEGER_1 

This is function cannot be changed with software in FODs and 
this variable will not have a effect on the performance 
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of the MAC. 


MAX.FRAME.S I ZE : := VALUE.INTEGER.1 

This is function cannot be changed with software in FODs and 
this variable will not have a effect on the performance 
of the MAC. 


MIN.FRAME.SIZE : := VALUE. INTEGERS 

This is function cannot be changed with software in FODs and 
this variable will not have a effect on the performance 
of the MAC. 


ADDRESS.SIZE : := VALUE. I NT EGER. 1 

This is function cannot be changed with software in FODs and 
this variable will not have a effect on the performance 
of the MAC. 
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STATUSJTYPE :: = CHOICE 


UNDEFINED_ERROR 

[0] 

VALUE_INTEGER_1 

SUCCESS 

[1] 

VALUE_INTEGER_1 

REFUSE_TO_COMPLY 

[2] 

VALUE_INTEGER_1 

NOT_SUPPORT ED 

[3] 

VALUE_INTEGER_1 

ERROR_ I N_PERFOR 

[4] 

VAUUE_INTEGER_1 

NOT_AVAI LABLE 

[5] 

VALUE_INTEGER_1 

BAD_PARAMET ER_ 1 D 

[6] 

VALUE_INTEGER_1 

BAD_PARAMETER_OPERAT ] ON 

[7] 

VA LUE_ I NT EGER_ 1 

BAD_PARAMETER_VALUE 

[8] 

VALUE_INTEGER_1 

BAD_EXPECTED_VALUE 

[9] 

VALUE_INTEGER_1 


\ 


These are responses to a command indicating the status of 
the command. Following are expected uses of these responses; 

UNDEFINED_ERROR - Request was not understood or no 

appropriate error message available. 
SUCCESS - A successful operation has been completed. 
REFUSE_TO_COMPLY - The operation was impossible or illegal. 
NOT_SUPPORTED - The operation is not supported or 
recogn i zed . 

ERROR_IN_PERFOR - A error was encountered 
during ope rat i on , 

NOT_AVA I LABLE - Information is not yet 
ava i I ab I e . 

BAD_PARAMETER_ID - Parameter ID was not 
recogn i zed . 

BAD_PARAMETER_OPERAT ION - Operation requested 

was not recognized 
BAD_PARAMETER_ VALUE - The Parameter 

va I ue was bad . 

BAD_EXPECTED_VALUE - The expected value was 

i I I ega I . 


EVENTJTYPES : IMPLICIT SEQUENCE 
} EVENT_CCASS - EVENT_C LASS_TYPES { 

EVENT_CLASS_TYPES ::= CHOICE 

} LOCAL [0] EVENT_I DENT I F 1 ER_TYPES | 

REMOTE [1] EVENT_ I DENT I F I ER_TYPES ( 

Events in this implementation are always LOCAL (as opposed 
to events that occurred in a remote node). 


EVENT_IDENTI FI ER_TYPES CHOICE 
\ DUP L I CAT E_ADDRESS 


[2] VALUE_1NTEGER_1 | 
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FAULTY_TRANSMI ITER 

[3] 

VALUE_INTEGER_1 

1 

XMIT_QUEUE_THRESHOLD_EXCEEDED 

[4] 

VA LU E_ I NT EG ER_ 1 

1 

RECEI VE_QUEUE_THRESHOLD_EXCEEDED 

[5] 

VALUE_INTEGER_1 

1 

WATCH_DOG_T IMEOUT 

[6] 

VALUE_INTEGER_1 

1 

FROZEN 

[7] 

VALUE_INTEGER_1 

1 

MAX_RETRY_ENCOUNTERED 

[10] 

VALUE_ INTEGERS 

1 

BAD_MESSAGE_SENT 

[11] 

VALUE_ADDRESS_1 

l 


These events are reported upon the discovery of the 
following conditions; 


DUPL1CATE_ADDRESS - Does nothing since FODs doesn’t report 
other addresses. 

FAULTY_TRANSM] TTER - Does nothing since FODs doesn’t report 
bad t ransm i 1 1 e rs . 

XMI T_QUEUE_THRESHOLD_EXCEEDED - Flagged when the MAC 

cannot get buffer space 
for outgoing data. 

RECEI VE_QUEUE_THRESHOLD_EXCEEDED - Flagged when the MAC 

cannot get buffer 
space for incoming 
data . 

WATCH_DOG_T IMEOUT - Flagged if the hordware wotch dog 
timer exp i res . 

FROZEN - Flogged when the MAC is frozen. Reported only 
once . 

MAX_RETRY_ENCOUNTERED - Flagged when a the max retry is 

encountered. Any IRL4 interrupt 
indicates the hardware retryed 
— beyond the ret ry limit. 

BAD_MESSAGE_SENT -Flagged when the MAC discovers a message 
which does not agrees with its indicated 
structure size (i.e. bad length field). 


ACT ION_VALUE_TYPES : :* CHOICE 

\ RESET [0] VALUE_INTEGER_1 | 

FREEZE/UNFREEZE [l] FREEZE.MAC j 

The ACT I ON_VALUE_TYPES allow the following; 


Reset va I ue_ i nteger_1 


any t h i ng : 
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A reset will flush all queues, set all operating 
parameters to their initial values, lose the token (if 
its holding it), and await work from either the media 
or the LLC. 

FREEZE/UNFREEZE FREEZE_MAC = 1 will freeze mac. 

= “1 will unfreeze mac. 

A FREEZE/UNFREEZE command with Freeze option will make the 
MAC main task ignore all queues but the SM. In effect the 
MAC is frozen to local service only. Packets arriving from 
remote nodes and from the LLC will be queued until the 
buffer is exceeded or the MAC is unfrozen. The token 
is still passed as normal. Commands from the Station 
Manager are processed while frozen. 


OPERAT I ON_COMMAND_TYPES CHOICE 


}TEST_« 

[0] 

READ_WR I TE_VALUE_TYPES 

i 

TEST_» 

[1] 

READJWR 1 TE_VALUE_TYPES 

i 

TEST_= 

[2] 

READ_WR I TE_VALUE_TYPES 

i 

TEST_<> 

[3] 

READ_WR I TE_VALUE__TYPES 

i 

TEST_<= 

[4] 

READJNR I TE_VALUE_TYPES 

i 

TEST__>= 

[5] 

READ_WR I TE_VALUE_TYPES 

i 

«_G I VEN_CONST ANT 

[6] 

GIVEN 

i 

»_G I VEN_CONSTANT 

[7] 

GIVEN 

i 

=_G I VEN_CONSTANT 

[8] 

GIVEN 

i 

<>_G I VEN_CONST ANT 

[9] 

GIVEN 

i 

<=_G I VEN_CONST ANT 

[10] 

GIVEN 

i 

>=_G I VEN_CONST ANT 

[11] 

GIVEN 

* 

The above operations 

expects a variable (we’ll call 

varl) to 

be internal. The complete 

structure includes either 

a 

variable or constant 

which 

we'll call var2. The constant is 


used to overwrite Varl in case the operation test true so in 
the case at two internal vars being tested a constant is 
also passed ip. The above operation commands imply the 
f o I lowing: 


TEST_« - i f 
TEST__» - i f 
TEST_= - i f 
TEST_<> - i f 
TEST_<= - if 


varl « var2 
varl » var2 
varl = var2 
varl <> var2 
varl O var2 


TEST_>= - if varl >= var2 
«_G I VEN_CONST ANT - if varl 
»_G I VEN_CONST ANT - if varl 
=_G I VEN_CONSTANT - if varl 


then va r 1=const an t 
then va r 1=const ant 
then va r 1=cons t an t 
then va r 1=const ant 
then va r 1=cons ton t 
then va r 1=const ant 
« constant then va r 1=constant 
» constant then vor 1=constont 
= constant then va r1=constant 
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<>_G I VEN_CONSTANT - if varl <> constant then va r 1=const ant 

<=_G I VEN_CONSTANT - if varl <= constant then va r 1 =cons t an t 

>=__G I VEN_CONSTANT - if varl <= constant then va r 1 =cons t an t 

Varl is a MAC parameter to be tested (internal). Its value 
is always returned along with a status. Var2 is a MAC 
parameter (internal) or a constant (external) used in the 
comparison of Varl (internal). Varl always refers to 
a variable located in the MAC. Var2 is either located 
in the MAC (a compare of two internal variables) or as 
a constant (external) passed in. In all cases a true 
test forces Varl to be a external constant. 

CONSTANT VALUE_I NTEGER.1 

VALUE„INTEGER_1 : IMPLICIT LONG.WORD 

VALUE_ADDRESS_1 : :* IMPLICIT LONG_WORD (32 BITS) 

VALUE_ADDRESS_1 6 ::= IMPLICIT ARRAY OF 16 LONG_WORDS 

(32 BITS EACH) 
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4.2.3 SYNTAX - 

STATION MANAGER INTERFACE SYNTAX 

The station manager communicates to the MAC across the Mil. 
The syntax of such communication is described below 
according to Abstract Syntax Notation One or ASN.l (ISO DIS 
8824). The information described is encoded to the basic 
coding rules as found in ASN.l (ISO DIS 8825). Some sample 
records follow the syntax notations. 


4.2.4 FORMAL SYNTAX SPECIFICATION 
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MESSAGE.RECORD . := [PRIVATE 0] CHOICE 
) [0] SM_MAC_LM_SET_VALUE . INVOKE 

[ 1 ] SM_MAC_ LM_S ET_VALUE . REPLY 

[2] SM_MAC_LM_GET_VALUE . INVOKE 

[3] SM_MAC_LM_GET_VALUE . REPLY 

[4] SM.MAC.LM.COMPARE.AND.SET.VALUE. INVOKE 

[ 5 ] SM_MAC_ LM_COMPAR E_AND_SET_VALUE . REPLY 

[6] SM_MAC_ ACTION. VALUE. INVOKE 

[7] SM_MAC_ACTION_ VALUE. REPLY 

[8] SM_MAC_EVENT_VALUE. NOTIFY 

[ 9 ] SM_MAC_EVENT_VALUE . REP LY \ 


SM_MAC_LM_SET_VALUE . INVOKE : := IMPLICIT SEQUENCE 
[ PARAMETER. TYPE READ.WRI TE.VALUE.TYPES , 

ACCESS.CONTROL. 1 NFO NULL } 

SM.MAC.LM.SET.VALUE . REPLY IMPLICIT SEQUENCE 
[ RETURN.VAL READ.WR I T E.VALUE.T YPES , 

STATUS STATUS.TYPE^ 

SM.MAC.LM.GET.VALUE . INVOKE IMPLICIT SEOUENCE 
} PARAMETER.TYPE READ.WRI TE.VALUE.TYPES . 

ACCESS.CONTROL. I NFO NULL [ 

SM.MAC.LM.GET.VALUE. REPLY : := IMPLICIT SEOUENCE 
j PARAMETER.TYPE READ.WRI TE.VALUE.TYPES , 
STATUS STATUS.TYPE [ 


SM.MAC.LM.COMPARE.AND.SET.VALUE . INVOKE : IMPLICIT SEOUENCE 
j PARAMETER.TYPE DUMMY.RW.TYPES , 

OPERAT I ON.COMMAND OPERAT I ON.COMMAND.TYPES . 

ACCESS.CONTROL. I NFO NULL [ 

SM.MAC.LMfCOMPARE.AND.SET.VALUE. REPLY : IMPLICIT SEQUENCE 
) RETURN.VAL - READ.WR I TE.VALUE.TYPES . 

STATUS STATUS.TYPE } 


SM.MAC.ACT10N.VALUE. INVOKE ::= IMPLICIT SEQUENCE 
j PARAMETER. ID ACTION.VALUE.TYPES , 

ACCESS.CONTROL. I NFO NULL[ 

SM.MAC.ACT ION. VALUE. REPLY ::= IMPLICIT SEQUENCE 
[ STATUS STATUS.TYPE , 

ACT I ON.REPORT NULL J 
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MAC_SM_ EVENT -VALUE. NOTIFY ::= IMPLICIT SEOUENCE 
} EVENT_1D ' EVENT_TYPES J 

MAC_SM_EVENT_VALUE. REPLY : := IMPLICIT SEOUENCE 
} STATUS STATUS_TYPE { 
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READ_WRITE_VALUE_TYPES : := CHOICE 

[0] MAC_TYPE 

[1] TS 

[2] SLOT_TIME 

[3] 1 NT ER_ FRAME_GAP 

[4] ATTEMPT_LIMI T 

[5] BACK_OFF_LIMIT 

[6] JAM_SIZE 

[7] MAX_FRAME_SI 2E 

[8] MIN_FRAME_SI ZE 

[9] ADDRESS_SI ZE 

[10] EVENT_ENABLE_MASK 

[11] MA_GROUP_ADDRESS 

[12] MA_GROUP_ADDR ESS_ALL 
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DUMMY.RW.TYPES : := CHOICE 

MAC_TYPE 

TS 

SLOT_T IME 

I NT ER.FRAME.GAP 

ATTEMPT_L IMI T 

BACK_OFF_LIMI T 

JAM_S1ZE 

MAX_FRAME_SIZE 

M1N_FRAME_SIZE 

ADDRESS_S1ZE 

EVENT_ENABLE_MASK 

MA_GROUP_ADDRESS 

MA_GROUP_ ADDR ESS_ALL 


[0] VALUE_INTEGER_1 

[1] VALUE_ADDRESS_1 

[2] VALUE_INTEGER_1 

[3] VALUE_INTEGER_1 

[4] VALUE_INTEGER_1 

[5] VALUE_INTEGER_1 

[6] VALUE. INTEGER.! 

[7] VALUE.INTEGER.1 

[8] VALUE.INTEGER.1 

[9] VALUE.INTEGER.1 

[10] VALUE.INTEGER.1 

[12] VALUE.INTEGER.1 

[13] VALUE.INTEGER.1 
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TS ::= VALUE.ADDRESS.1 

NS ::= VALUE.ADDRESS.1 

SLOT.TIME VALUE. I NT EGER. 1 

EVENT. ENAB L E.MASK : := EVENT_ENABLE_B ITS 

MA.GROUP. ADDRESS : := VALUE.ADDRESS.1 

MA.GROUP.ADDR ESS.A L L : := VALUE.ADDRESS.1 6 

FREEZE.MAC : VALUE. I NT EGER. 1 


MAC.TYPE : : = 03h 
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STATUS.TYPE ':= CHOICE 


UNDEFINED.ERROR 

[ 0 ] 

VALUE. I NT EGER. 

SUCCESS 

[i] 

VALUE. INTEGER. 

R E FUS E.T 0_COMP L Y 

[2] 

VALUE. INTEGER, 

NONSUPPORTED 

[3] 

VALUE. INTEGER. 

ERROR_ I N.PREFOR 

[4] 

VALUE. INTEGER. 

NOT_AVAI LABLE 

[5] 

VALUE. INTEGER. 

BAD.PARAMETER.ID 

[6] 

VALUE. INTEGER. 

BAD_PARAMETER_OPERERATION 

[7] 

VALUE. INTEGER. 

BAD.PARAMET ER_ VA LU E 

[8] 

VALUE.INTEGER. 

BAD.EXPECTED.VALUE 

[9] 

VALUE. I NTEGER. 


EVENT_TYPES : := IMPLICIT SEQUENCE 
} EVENT_CLASS EVENT_CLASS_TYPES } 

EVENT_C LASS_TYPES : CHOICE 

| LOCAL [0] EVENT. IDENTI FI ER_TYPES | 

REMOTE [1] EVENT. 1 DENT 1 FI ER.TYPES j 


EVENT. I DENT I F I ER.TYPES 


CHOICE 


DUP L I CAT E.ADDR ESS 

[2] 

VALUE.INTEGER.1 

FAU LT Y.TRANSM I TT ER 

[3] 

VALUE.INTEGER.1 

XMI T.QUEUE.THRESHOLD.EXCEEDED 

[4] 

VALUE.INTEGER.1 

R EC E I V E.QU EU E.T HR ESHO LD. EXC E ED ED 

[5] 

VALUE.INTEGER.1 

WAT CH.DOG.T I MEOUT 

[6] 

VALUE.INTEGER.1 

FROZEN 

[7] 

VALUE.INTEGER.1 

MAX.RETRY.ENCOUNTERED 

[10] 

VALUE.INTEGER.1 

BAD.MESSAGE.SENT 

[11] 

VALUE. ADDRESS.1 

✓ENT.ENABLE.BITS : := BIT STRING 

DUP LI CATE. ADDRESS 

(2), 


FAULTY.TRANSMI TTER 

(3). 


XMI T.OUEUE.THRESHOLD.EXCEEDED 

(4). 


RECE I VE.QUEUE.THRESHOLD.EXCEEDED 

(5). 


WATCH.DOG.TI MEOUT 

(6), 


FROZEN * 

(7), 


MAX.RETRY.ENCOUNTERED 

(10) 


BAD.MESSAGE^SENT 

(11) 

i 


— Where 1 is enabled 


ACTION.VALUE.TYPES : CHOICE 

i RESET [0] VALUE.INTEGER.1 | 

FREEZE/UNFREEZE [1] FREEZE.MAC { 


OPERATION.COMMAND.TYPES ::= CHOICE 

| TEST_« [0] DUMMY.RW.TYPES 

TEST_» [1] DUMMY.RW.TYPES 
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TEST_= ‘ 

[2} 

DUMMY. 

_RW_TYPES 

TEST_<> 

[3] 

DUMMY. 

_RW_TYPES 

TEST_<= 

[4] 

DUMMY. 

_RW_TYPES 

TEST_>= 

[5] 

DUMMY. 

_RW_TYPES 

«_G I VEN_CONST ANT 

[6] 

GIVEN 


»_G I VEN_CONST ANT 

[7] 

GIVEN 


=_G I VEN_CONST ANT 

[8] 

GIVEN 


<>_G I VEN_CONST ANT 

[9] 

GIVEN 


<=_G I VEN_CONST ANT 

[10] 

GIVEN 


>=_GlVEN_CONSTANT 

[11] 

GIVEN 



GIVEN : := CHOICE 

} [0] VALUE_1NTEGER_1 
[1] VALUE_ADDRESS_1 


! 


CONSTANT VALUE_INTEGER_1 

VALUE_INTEGER_1 ::= IMPLICIT INTEGER 

VALUE_ADDRESS_1 :: = IMPLICIT LONG_WORD (32 BITS) 

VALUE_ADDRESS_1 6 : := IMPLICIT ARRAY OF 16 LONG.WORDS 

(32 BITS EACH) 
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4.2.5 IEEE 802.4 SM COMMAND DESCRIPTIONS - 


SM_MAC_LM_SET_VALUE . INVOKE 
1 PARAMETER.TYPE. ACCESS_CONTROl_INFO \ 

The objective of the SM_MAC_LM_SET_VALUE. INVOKE commond by 
the SM is to set o volue in the MAC os defined by the 
parometer_type structure. This structure specifies both the 
vorioble to be set ond the volue to which it is set. 

SM_MAC_LM_SET_VALUE . REPLY 
} STATUS { 

The objective of the reply by the MAC to the SM is to 
indicote the success or foilure of o previous 
SM_MAC_LM_SET_ VALUE. INVOKE. The SM expects the MAC to 
overwrite the SM_MAC_LM_SET_VALUE . INVOKE with the 
SM_MAC_LM_SET_VALUE . REPLY thus ol lowing the SM to releose 
the message buffer. 


SM_MAC_LM_GET_ VALUE. INVOKE 
} PARAMETER_TYPE , ACCESS_CONTROL_INFO j 

The objective of the SM_MAC_LM_GET_VALUE. INVOKE commond by 
the SM is to get a value in the MAC as defined by the 
porometer_type structure. This structure specifies the 
varioble to be read. 

SM_MAC_LM_GET_ VALUE . REPLY 
\ PARAMET ER_TYPE , STATUS { 

The objective of the reply by the MAC to the SM is to 
indicate ~ the success or foilure of a previous 
SM_MAC_LMJSET_VALUE. INVOKE. The SM expects the MAC to 
overwrite the SM_MAC_LM_GET_ VALUE. INVOKE with the 
SM_MAC_LM_GET_ VALUE. REPLY t hus a I I owi ng t he SM to releose 
the message buffer. 


SM_MAC_LM_COMPARE_AND_SET_VALUE . INVOKE 
j PARAMETER.TYPE, OPERAT I ON_COMMAND , 
ACC ESS_CONTROL_ INFO j 


The Compore and Set value command forces the MAC to do a 
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comparison (<5f either a given constant or of a MAC variable) 
against a MAC variable. If the comparison is true then the 
MAC variable is over written. The PARAMETER_TYPE indicates 
the parameter to be over written and the value to use. The 
OPERAT ION_COMMAND structure specifies the comparison to do, 
and the constant or MAC variable to use in the comparison. 

SM_MAC_LM_COMPARE_AND_SET_VALUE . REPLY 

} STATUS, RETURN_VAL } 

The objective of the reply by the MAC to the SM is to 
indicate the success or failure of a previous 
SM_MAC_LM_COMPARE_AND_SET_ VALUE. INVOKE . The SM expects the 
MAC to overwrite the SM_MAC_LM_COMPARE_AND_SET_ VALUE . INVOKE 
with the SM_MAC_LM_COMPARE_AND_SET_ VALUE . REPLY thus allowing 
the SM to release the message buffer. 


SM_MAC_ACT I ON_VALUE . INVOKE 
} PARAMETERS D , ACCESS_CONTROL_INFO { 

The objective of the SM_MAC_ACT ION_VALUE . INVOKE command by 
the SM is to force a MAC operation (i.e. reset, freeze) in 
the MAC as defined by the parameter_ID structure. This 
structure specifies the action to be performed. 

SM_MAC_ACT IONJ/ALUE . REPLY 
1 STATUS, ACTION.REPORT \ 

The objective of the reply by the MAC to the SM is to 
indicate the success or failure of a previous 
SM_M AC_ ACT I ON_ VALUE. INVOKE . The SM expects the MAC to 
overwrite the SM_MAC_ ACTION. VALUE . INVOKE with the 
SM_MAC_ACT 1 ON_VALUE .REPLY thus allowing the SM to release 
the messofte buffer. 


MAC_SM_EVENT_VALUE . NOT I FY 
\ EVENT.ID j 

The objective of the MAC__SM__EVENT_ VALUE . NOT I FY command by 
the MAC is to report a event which has occurred in the MAC 
as defined by the EVENT_ID structure. This structure 
specifies the Event and an integer. These events can be 
masked by setting the EVENT_MASK variable. 
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MAC1SM_EVENT_VALUE . REPLY 
\ STATUS \ 


The objective of the following reply by the SM 
to indicate the success or failure of 
MAC_SM_EVENT_V A IUE . NOTIFY. The MAC expects 

overwrite the MAC_SM_EVENT_VALUE . NOT I FY 

MAC_SM_EVENT_VALUE . REPLY thus allowing the MAC 
the message buffer. 


to the MAC i s 
a previous 
the SM to 
with the 
to release 
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Variables which can be accessed are; 


VARIABLE NAME 

TS 

NS 

SLOT_T IME 

Hl_PRI _TOK EN__HO LD_T I ME 

MAX_AC_4_R0T AT I ON_T I ME 

MAX_AC_2_R0T AT I ON_T I ME 

MAX_AC_0_ROT AT I ON_T I ME 

MAC_R I NG_MA I NT ENANC E_ROT AT I ON_T I ME 

R I NG_M A I N T EN ANC E_T 1 MER_ I N I T I A L_VA LU E 

MAX_ I NT ER.SO L I C I T .COUNT 

Ml N_POST_SI L ENC E.PRE AMB L E. LENGTH 

EVENT. ENABLE.MASK 

MAX_RETRY_L 1MI T 

MA.GROUP.ADDRESS 

CHANNEL.ASS IGNMENTS 

TRANSMI TTED.POWER.LEVEL.ADJUSTMENT 

TRANSM I TT ED.OUTPUT. INHIBITS 

RECEI VED.S I GNA L.SOURCES 

SIGNAL I NG.MODE 

RECEIVED_SIGNAL_LEVEL_REP0RT1NG 

LAN.TOPOLOGY.TYPE 

MAC.TYPE 


Read Write Rea I 
x x 

X XX 

X X 

X XX 

X X 

X X 

X X 

X X 

X X 

X X 

X X 

X XX 

X XX 

X XX 

X X 

X X 

X X 

X X 

X X 

X X 

X X 


Emu I ated 

X 

X 

X 

X 

X 

X 

X 

X 

X 


X 

X 

X 

X 

X 

X 

X 
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READ_WRI TE_ 

_VALUE_TYPES : CHOICE J 

[0] 

MAC_TYPE 

M 

NS 

[2] 

SLOT_T IME 

[3] 

H I _PR I_TOK EN_HO LD_T I ME 

[4] 

MAX_AC_4_R0T AT 1 ON_T IME 

[5] 

MAX_AC_2_ROTAT I ON_T I ME 

[6] 

MAX_AC_0_ROT AT I ON_T IME 

[7] 

MAC JR I NG J4A I NT ENANC E_ROT AT I ON_T I ME 

[8] 

R I NG_MA I NT ENANCE.T I MER_ I N I T I A L_VAl_UE 

[9] 

MA X_ I NT ER_SO L I C I T_COUNT 

[10] 

MIN.POST.SI LENCE_PREAMBLE_LENGTH 

[11] 

event_enabie_mask 

[12] 

max_retry_limit 

[13] 

MA_GROUP_ADDRESS 

[14] 

MA_GROUP_ADDRESS_ALL 

[15] 

CHANNEL_ASS I GNMENTS 

[16] 

TRANSMITTED J>OWER_LEVEL_ADJUSTMENT 

[17] 

TRANSM I TTED_OUTPUT _I NH I B I TS 

[18] 

REC E I V ED_S I GN A L_SOURC ES 

[19] 

S I GNA L I NG_MOD E 

[20] 

RECE I VED_S I GNAL_LEVEL_REPORT I NG 

[21] 

LAN_T OPOLOGY_TYPE 

[22] 

TS 
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TS ::= VALUE_ADDRESS_1 

This variable represents the address of this station. Since 
FODS has its address set in hardware this variable has no 
effect on MAC performance. 


NS ::= VALUE_ADDRESS_ 1 

This variable represents the address of the next station. 

The IEEE 802.4 would normally calculate this address however 
in this implementation this address must be set in order for 
the MAC to know where the next station is in order to pass 
the token. 


SLOT_TIME : := VALUE_1 NTEGER_1 

This variable represents the slot time of this station. This 
is the maximum time this station must wait on another 
station to respond to a transmition. The FODS knows this as 
T_Gap. Since FODS has T_Gap set in hardware this variable 
has no effect on MAC performance. 


Hl_PRI_TOKEN_HOLD_T IME : VALUE_ I NTEGER_1 

This variable represents the token hold time of this 
station. This is the maximum time this station can hang on 
to the token. If this time expires then the token must be 
passed . 


MAX_AC_4_R0T AT I ON_T I ME : :« VALUE_INTEGER_1 

This variable can be written to and read but is not used in 
this implementation to perform a function and will have no 
effect orv-^he MAC performance. 


MAX_AC_2_R0T AT I ON_T I ME : VALUE_INTEGER_1 

This variable can be written to and read but is not used in 
this implementation to perform a function and will have no 
effect on the MAC performance. 


MAX_AC_0_ROT AT I ON_T I ME : :« VA LU E_ I NT EG ER_ 1 


This variable can be written to and read but is not used in 


TOKEN/STAR BUS MAC SOFTWARE USERS DOCUMENT 
INTERFACES 


Page 39 
20 July 1987 


this implementation to perform a function and will have no 
effect on the MAC performance. 

MAC_RING_MAINTENANCE_ROTATION_TIME : := VALUE_I NTEGER_1 

This variable can be written to and read but is not used in 
this implementation to perform a function and will have no 
effect on the MAC performance. 


RING_MAINTENANCE_T IMER_INIT l Al_VALUE : := VALUER NTEGER_t 

This variable can be written to ond read but is not used in 
this implementation to perform a function and will have no 
effect on the MAC performance. 


MAX_ I NT ER_$OL l C I T_COUNT : :* VALUE_I NTEGER_1 

This variable can be written to and read but is not used in 
this implementation to perform a function and will have no 
effect on the MAC performance. 


MIN_P0ST_S1 LENCE_PREAMBLE_ LENGTH : := V A LUE_ I NT EG ER_ 1 

This variable can be written to ond read but is not used in 
this implementation to perform a function and will have no 
effect on the MAC performance. 


JN_RING_DESIRED : := VALUE_1NTEGER_1 

This variable will allow the MAC to participate in the ring 
when set to one. When the command initially comes to set 
this variable to a one the token is kicked off (presumable 
for the first time). Sending multiple IN_RING_DESIRED 
commands dTf one will generate multiple tokens in the media. 
This is odeviation from IEEE 802.4, but the described usage 
of 

this variable will be very 

useful for testing. A negative one command will tell the MAC 
to consume the next tokens it receives (i.e. it will do 
nothing and not pass the token currently held). This will, 
of 

course, lock up the media when the lost token is consumed so 
at some point it will be necessary to set IN_RING_DESIRED to 
one again. 
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This work is implemented by setting f o rce_token_pass to true 
and calling MAC_T ransm i t .queue ( ) when the IN.RING.DESIRED = 

1 or by sending a NULL work package to the interrupt 
routines when IN.RING.DESIRED = -1 (this will consume the 
current or next token). Keep in mind that this system will 
automatically attempt to consume extra tokens so the station 
manager may have to watch the dual token event reports if it 
really wishes to keep track of multiple tokens. 


EVENT.ENABLE.MASK : := EVENT.ENABLE.B I TS 

EVENT.ENABLE.BITS : :« BIT STRING 
} NS.CHANGED (0), 

NS_NULL (1), 

DUPL I CAT E_ADDRESS (2) , 

FAULTY_TRANSMI TTER (3) , 

XMIT.QUEUE.THRESHOLD.EXCEEDED (4) , 
RECE I VE.QUEUE.THRESHOLD.EXCEEDED (5) . 
WATCH.DOG.T I MEOUT (6) , 

FROZEN (7), 

TOKEN. LOST (8), 

DUAL.TOKEN (9), 

MAX.RETRY.ENCOUNTERED (10) { 


— Where 1 i s enab I ed 

The MAC will report events when discovered and the 
appropriate bit is set in the MASK above. Bit 0 is the 
NS.Station, bit 1 is the NS.NULL etc. These bits are 
inspected each time the event has occurred and the MAC task 
is active. The event is reported only once whenever the 
actual occurence is detected. 


MAX.RETRY. LIMIT : VALUE. I NT EGER. 1 

This is tlie moximum number of times that a packet will be 
retransmitted when the acknowledgement indicates a bad 
t ransm i 1 1 ron .. Si nee this is o connectionless system this 
variable should not be used. However, it will be loaded into 
the hardware transmit register whenever a packet is to be 
sent and the hardware will actually perform retrys. 


MA.GROUP.ADDRESS : VALUE.ADDRESS. 1 

The MAC can respond to a group of group oddresses. This is 
one of two methods for the Station Manager to tell the MAC 
which addresses are acceptable. This implementation will 
support a total of 16 group addresses. A positive value in 
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this command will set this address as part of the group 
addresses (unless there all used up) and a negative address 
will delete this address from the table. 

MA_GROUP_ADDRESS_ALL : := VALUE_ADDRESS_1 6 

The MAC can respond to a group of group addresses. This is 
one of two methods for the Station Manager to tell the MAC 
which addresses are acceptable. This implementation will 
support a total of 16 group addresses. This command will 
write or read all 16 addresses at once. Addresses which ore 
not valid addresses should be set to a negative one. 
Therefore only positive addresses will be passed in with 
this command unless there a negative one (a null address). 


CHANNEL_ASS I GNMENTS : VALUE_INTEGEp_1 

This variable can be written to and read but is not used in 
this implementation to perform a function ond will have no 
effect on the MAC performance. 

TRANSMI TTED_POWER_LEVEL_ADJU$TMENT : := VALUE_INTEGER_1 

This variable can be written to and read but is not used in 
this implementation to perform a function and will have no 
effect on the MAC performance. 

TRANSMITTED_OUTPUT_INHIBITS ::*= VALUE_INTEGER_1 

This variable can be written to and read but is not used in 
this implementation to perform a function and will have no 
effect on the MAC performance. 


R ECE I VED GNAL_SOURCES : VALUE_1NTEGER_1 

This variable con be written to and read but is not used in 
this implementation to perform a function and will hove no 
effect on the MAC performance. 


SIGNALING_MODE : VALUE_ INTEGERS 

This variable can be written to and read but is not used in 
this implementation to perform a function and will have no 
effect on the MAC performance. 
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RECEI VED_SIGNAL_LEVEL_REPORT ING : := VALUE_1NTEGER_1 

This variable can be written to and read but is not used in 
this implementation to perform a function and will have no 
effect on the MAC performance. 

LAN_TOPOLOGY_TYPE : := VALUE_ INTEGERS 

This variable can be written to and read but is not used in 
this implementation to perform a function and will have no 
effect on the MAC performance. 


FREEZE.MAC VA LUE_ I NT EG ER_ 1 

This variable when set to one will freeze the MAC from 
taking any data from the local LLC. A negative one will 
unfreeze it and allow any queued messages to be processed. 
This will cause a burst effect and may cause loss of data 
due to the connectionless nature of the system and the 
I im i ted but f er space . 

MAC_TYPE : 04h 

This variable is a read only variable and indicates which 
version of MAC is responding. 
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STATUS_TYPE' : := CHOICE 


UNDEF I NED_ERROR 

[ 0 ] 

VA LUE_ I NT EGER_ 1 

SUCCESS 

[i] 

VALUE. JNTEGER.I 

REFUSE_TO_COMPLY 

[2] 

VALUE_INTEGER_1 

NONSUPPORTED 

[3] 

VALUE.INTEGER.1 

ERROR_ I N_PERFOR 

[4] 

VALUE.INTEGER.1 

NOT_AVAI LABLE 

[5] 

VALUE_INTEGER_1 

B AD_PARAMET ER_ I D 

[6] 

VALUE_INTEGER_1 

BAD_PARAMET ER_OP ER AT I ON 

[7] 

VALUE.INTEGER.1 

bad_paramet er_v a lue 

[8] 

VALUE. INTEGERS 

BAD_EXPECTED_ VALUE 

[9] 

VALUE_INTEGER_1 


These are responses to a command indicating the status of 
the command. Following are expected uses of these responses; 

UNDEFI NED_ERROR - Request was not understood or no 

appropriate error message available. 
SUCCESS - A successful operation has been completed. 
REFUSE_TO_COMPLY - The operation wos impossible or illegal. 
NONSUPPORTED - The operation is not supported or 
recogn i red . 

ERROR_IN_PERFOR - A error was encountered 
during operot i on . 

NOT_AVA I LABLE - Information is not yet 
ava i I ab I e . 

BAD_PARAMETER_JD - Parameter ID was not 
recogn i zed . 

BAD_PARAMETER_OPERATION - Operation requested 

was not recognized 
BAD_PARAMETER_VALUE - The Parameter 

value was bad. 

BAD_EXPECTED_VALUE - The expected value was 

i I I ega I . 


EVENNTYRfS : IMPLICIT SEQUENCE 

j EVENT_CtASS EVENT_C LASS_T YP ES \ 

EVENT_CLASS_TYPES : :* CHOICE 

} LOCAL [0] EVENNIDENTI FI ER_TYPES | 

REMOTE [1] EVENT_IDENT I FI ER_TYPES } 

Events in this implementation are always LOCAL (as opposed 
to events that occurred in a remote node). 


EVENT_ I DENT I F I ER_TYPES CHOICE 

\ NS_CHANGED 


[0] VALUE_INTEGER_1 | 
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NS_NULL ‘ [1] VALUE_ INTEGERS 
DUP L I CAT E_ ADDRESS [ 2 ] VALUE_ I NT EGER_ 1 
FAU LT Y_TRANSM I TT ER [ 3 ] VALUE_ 1 NTEGER_ 1 
XMI T_OUEUE_THRESHOLD_EXCEEDED [4] VALUE_INTEGER_1 
RECE I VE_QUEUE_THRESHOLD__EXCEEDED [5] VALUE_INTEGER_1 
WAT ChLDOG_T I MEOUT [6] VA LU E_ I NT EG ER_ 1 
FROZEN [7] VALUE_INTEGER_1 
TOKEN_LOST [8] VALUE_INTEGER_1 
DUAL_TOKEN [9] VALUE_INTEGER_1 
MAX_RETR Y_ ENCOUNTER ED [10] VALUE_INTEGER_1 
BAD_MESSAGE_SENT [ 1 1 ] VALUE_ADDRESS_1 


These events are reported upon the discovery of the 
following conditions; 

NS_CHANGED - Flogged when the event routine discovers o 
change in the NS 

address . 

NS_NULL - Flagged when the NS is set to NULL 

DUP L I CAT E_ADDRESS - Does nothing since FODs doesn't report 
other addresses. 

FAULTY_TRANSMITTER - Does nothing since FODs doesn't report 
bad transmitters. 

XMI T_QUEUE_THRESHOLD_EXCEEDED - Flagged when the MAC 

cannot get buffer space 
for outgoing data. 

RECE I VE_QUEUE_THRESHOLD_EXCEEDED - Flagged when the MAC 

cannot get buffer 
space for incoming 
dot a . 

W A T CH_DOQ^f I MEOUT - Flagged if the hardware watch dog 
~ timer expi res . 

FROZEN - Flagged when the MAC is frozen. Reported only 
once . 

TOKEN_LOST - Flagged when the token is detected as 
I ost . 

DUAL_TOKEN - Flagged when a extra token is discovered. 

MAX_RETRY_ENCOUNTERED - Flagged when a the max retry is 

encountered. Any IRL4 interrupt 
indicates the hardware retryed 
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beyond the retry limit. 

BAD_MES$AGE_SENT -Flagged when the MAC discovers a message 
which does not agrees with its indicated 
structure size (i.e. bad length field). 


ACT ION_VALUE_TYPES ::= CHOICE 

\ RESET [0] VALUE_INTEGER_1 | 

FREEZE/UNFREEZE [ 1 ) FREEZE_MAC | 

ENT ER_THE_R I NG [2] I N_R I NG_DES I RED \ 

The ACT I ON_VALUE_TYPES allow the ^ Mowing; 

Reset vo I ue_ i ntege r_1 = anything: 

A reset will flush all queues, set all operating 
parameters to their initial values, lose the token (if 
its holding it), and await work from either the media 
or the LLC . 

FREEZE/UNFREEZE FREEZE_MAC = 1 wi I I freeze mac. 

= -1 will unfreeze mac. 

A FREEZE/UNFREEZE command with Freeze option will make the 
MAC main task ignore all queues but the SM. In effect the 
MAC is frozen to loco) service only. Packets arriving from 
remote nodes ond from the LLC will be queued until the 
buffer is exceeded or the MAC is unfrozen. The token 
is still passed as normal. Commands from the Station 
Monoger ore processed while frozen. 

ENTER_THE_RING I N_R I NG_DES I RED = 1 create token 

* -I consume token 

A ENTER_TME_R1NG command will convince the MAC it is the 
holder of^the token. If this command is sent twice in 
a row the.fT the MAC will; 

1) In the case of the MAC currently holding the token, do 
noth i ng . 

2) In the case of the MAC about ready to receive the 
token, a dual token may be reported and the extra token 
is consumed (on inherent operation in this design). 

3) In the case of the MAC in a idle state, the token 
is token and passed on when appropriate. Since this is 
o CSMA/CD machine it can operate with two tokens for 
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some time before, it discovers and consumes one of them 
(802.4 machines also have this ability but are far less 
forgiving of collisions). 


OPERATION_COMMAND_TYPES :: = CHOICE 

} T EST_« [0] READ.WR I T E_VAUJE_TYPES 

TEST_» [1] READ_WR1TE_VALUE_TYPES 

TEST_— [2] READ_WR I TE_VALUE_TYPES 

TEST_<> [3] READ_WR I TE_VALUE_TYPES 

TEST_<= [4] R£AD_WRI TE_VALUE_TYPES 

TEST_>= [5] READ_WR 1 TE_VALUE_TYPES 

«_G I V E N__CONS T AN T [ 6 ] GIVEN 
»_G I VEN.CONSTANT [ 7 ] GIVEN 
=_GIVEN_CONSTANT [8] GIVEN 
<>_G t VEN_CONST ANT [9] GIVEN 
<=_G I VEN_CONST ANT [10] GIVEN 


>=_G I VEN_CONST ANT [11] GIVEN 


The above operations expects a variable (we’ll call varl) to 
be internal. The complete structure includes either a 
variable or constant which we’ll coll var2. The constant is 


used to overwrite Varl in case the operation test true so in 
the case of two internal vars being tested a constant is 
also passed in. The above operation commands imply the 
f ol lowing: 


TEST_« - if varl « var2 then var1=constant 
TEST_» - if varl » var2 then varl^constant 
TEST_=s - if varl = var2 then var Inconstant 

TEST_<> - if varl <> var2 then var1=constant 

TEST_<s= - if varl <= vor2 then var1=constont 

TEST_>=* - i f varl >= var2 then var1=constant 

«_GI VEN_CONSTANT - if varl « constant then var1~constant 

»_GI VEN_CONSTANT - if varl » constant then var1~constant 

*=_G I VEN_CONSTANT - if varl = constant then var1=constont 

<>_GI VEN_CONSTANT - if varl <> constant then var1=constant 

<=_GI VEN_€QNSTANT - if varl <» constant then var Inconstant 

>*_GI VEN_£C)NSTANT - if varl <» constant then var1=constant 


Varl is a MAC parameter to be tested (internal). Its value 
is always returned along with a status. Var2 is a MAC 
parameter (internal) or a constant (external) used in the 
comparison of Varl (internal). Varl always refers to 
a variable located in the MAC. Var2 is either located 
in the MAC (a compare of two internal variables) or as 
a constant (external) passed in. In all cases a true 
test forces Varl to be a external constant. 


CONSTANT 


VALUE_INTEGER_1 
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IMPLICIT LONGJVORD 

: := IMPLICIT LONG_WORD (32 BITS) 

6 IMPLICIT ARRAY OF 16 LONG_WORDS 

(32 BITS EACH) 
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4.2.6 SYNTAX - 

STATION MANAGER INTERFACE SYNTAX 

The station manager communicates to the MAC across the Mil. 
The syntax of such communication is described below 
according to Abstract Syntax Notation One or ASN.l (ISO DIS 
8824). The information described is encoded to the basic 
coding rules as found in ASN.l (ISO DIS 8825). Some sample 
records follow the syntax notations. 


4.2.7 FORMAL SYNTAX SPECIFICATION - 
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MESSAGE.RECORD : := [PRIVATE 0] CHOICE 
| [0] SM.MAC.LM.SET.VALUE . INVOKE 

[1] SM.MAC.LM.SET.VALUE . REPLY 

[2] SM.MAC.LM.GET.VALUE . INVOKE 

[3] SM_MAC_LM_GET_VALUE. REPLY 

[4] SM_MAC_LM_COMPARE_AND_SET_ VALUE. INVOKE 

[5] SM_MAC_ LM_COMPAR E_ AND_S ET_ VA LU E .REPLY 

[ 6 ] SM_MAC_ACT ION_ VALUE . 1 NVOKE 

[7] SM.MAC.ACT ION.VALUE . REPLY 

[8] SM_MAC_EVENT_VALUE. NOTIFY 

[9] SM.MAC.EVENT.VALUE. REPLY [ 


SM.MAC.LM.SET.VALUE. INVOKE IMPLICIT SEQUENCE 
} PARAMETER_TYPE READ.WR1 TE.VALUE.TYPES . 

ACCESS_CONTROL_ I NFO NULL \ 

SM_MAC_LM_SET_VALUE . REPLY : :« IMPLICIT SEQUENCE 
[ RETURN_VAL READ.WR I T E_VA LUE_T YPES , 

STATUS STATUS_TYPEj 

SM_MAC_LM_GET_VALUE. INVOKE : : = IMPLICIT SEQUENCE 
[ PARAMETER_TYPE READ.WR I T E_VALUE_TYPES , 

ACCESS_CONTROL_ I NFO NULL } 

SM_MAC_LM_GET_VALUE . REPLY : :« IMPLICIT SEQUENCE 
j PARAMETER_TYPE READ.WR I T E_VA LUE_T YPES , 

STATUS STATUS_TYPE [ 


SM_MAC_LM_COMPARE_AND_SET_ VALUE. INVOKE : :« IMPLICIT SEQUENCE 
} PARAMETER. TYPE DUMMY.RW.TYPES , 

OP ERAT 1 ON.COMMAND OPERAT I ON_COMMAND_T YPES , 

ACC ESS_CONTROL_ I NFO NULL [ 

SM.MAC.LM^COMPARE.AND.SET. VALUE. REPLY : :« IMPLICIT SEQUENCE 
I return~Val READ_WR1TE_VALUE_TYPES, 

status STATUS.TYPE j 


SM.MAC.ACT I ON. VALUE. INVOKE : IMPLICIT SEQUENCE 
j PARAMETER. ID ACTION.VALUE.TYPES , 

ACCESS.CONTROL.INFO NULL j 

SM.MAC.ACT I ON. VALUE .REPLY : := IMPLICIT SEQUENCE 
j STATUS STATUS.TYPE , 

ACTION.REPORT NULL j 
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ACT10N_VALUE_TYPES : 

: := CHOICE 

) RESET 

[0] 

VALUE_I NTEGER_1 

FREEZE/UNFREEZE 

[i] 

FREEZE_MAC 

ENTER_THE_RING 

[2] 

I N_R I NG_DES I RED 


OPERAT I ON_COMMAND_TYPES : 

= CHOICE 

) TEST_« 

[0] 

DUMMY __RW_TYPES 

TEST_» 

[i] 

DUMMY_RW_TYPES 

TEST_= 

[2] 

DUMMY_RW_TYPES 

TEST_<> 

[ 3 ] 

DUMMY_RW_TYPES 

TEST_<= 

14) 

DUMMY_RW_TYPES 

TEST_>= 

[ 5 ] 

DUMMY_RW_TYPES 

«_GIVEN_CONSTANT 

[ 6 ] 

GIVEN 

»_G I VEN_CONSTANT 

I?) 

GIVEN 

•=_G I VEN_CONS T ANT 

[8] 

GIVEN 

<>_G I VEN_CONS T ANT 

[9] 

GIVEN 

<=_G I VEN_CONST ANT 

[10] 

GIVEN 

>=_G I VEN_CONSTANT 

["] 

GIVEN 


GIVEN : :» CHOICE 


) [0] VALUE_INTEGER_1 

1 

[1] VALUE_ADDRESS_1 

} 



CONSTANT ::= VALUE_INTEGER_1 

VALUE_INTEGER_1 : := IMPLICIT INTEGER 

VALUE_ADDRESS_1 : IMPLICIT LONG.WORD (32 BITS) 

VALUE_ADDRESS_1 6 : IMPLICIT ARRAY OF 16 LONG_WORDS 

(32 BITS EACH) 


TOKEN/STAR BUS MAC 
INTERFACES 


mac_sm_ event. value 

} EVENT. ID 

MAC_SM_EVENT_VALUE 
} STATUS 


SOFTWARE USERS DOCUMENT 


20 


NOTIFY ::= IMPLICIT SEOUENCE 
EVENT.TYPES } 

REPLY ::= IMPLICIT SEQUENCE 
STATUS.TYPE } 


Poge 50 
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READ.WRITE, 

_VALUE_TYPES : := CHOICE } 

[0] 

MAC.TYPE 

[1] 

NS 

[2] 

SLOT.TIME 

[3] 

HI_PR I _TOKEN_HOLD_T I ME 

[4] 

MAX_AC_4_R0T AT I ON_T I ME 

[5] 

MAX_AC_2_ROT AT 1 ON_T I ME 

[6] 

MAX_AC_0_ROT AT I ON_T I ME 

[7] 

MAC_R I NG_MA I NTENANC E_ROT ATI ON_T I ME 

[8] 

R I NG_MA I NT ENANCE_T I MER_ I N I T I AL_VALUE 

[9] 

MAX_ I NT ER_SOL I C I T_COUNT 

[10] 

MIN_POST_SI L ENC E_PREAMB LE_ L ENGTH 

[11] 

EVENT_ENABL E_MASK 

[12] 

MAX_RETRY_LIMIT 

[13] 

MA_GROUP_ADDR ESS 

[14] 

MA_GROUP_ADDRESS_ALL 

[15] 

CHANNEL. ASS I GNMENTS 

[16] 

TRANSMITTED_POWER_LEVEL_ADJUSTMENT 

[17] 

TRANSM I TTED_OUTPUT_ INHIBITS 

[18] 

RECE I VED.SI GNAL.SOURCES 

[19] 

SIGNAL I NG.MODE 

[20] 

RECEI VED_SIGNAL_LEVEL_REPORT I NG 

[21] 

LAN_TOPOLOGY_TYPE 

[22] 

TS 
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DUMMY_RW_TYPES ::= CHOICE } 

MAC_TYPE 

NS 

SlOT_TIME 

H I _PR I _TOKEN_HOLD_T IME 

MAX_AC_4_ROTAT I ON_T I ME 

MAX_AC_2_ROTAT ION_T I ME 

MAX_AC_0_ROT AT 1 ON_T I ME 

MAC_R I NG_MA I NTENANCE_ROTAT ION_T IME 

R I NG_MA I NTENANCE_T I MER_ 1 N I T I AL_ VALUE 

MAX_ I NT ER_SOL I C 1 T_COUNT 

MIN_POST_SI LENCE_PREAMBLE_LENGTH 

EVENT_ENABLE_MASK 

MAX_RETRY_LIMIT 

MA_GROUP_ ADDRESS 

MA_GROUP_ADDRESS_A L L 

CHANNE L_ASS I GNMENTS 

TRANSMITTED_POWER_LEVEL_ADJUSTMENT 

TRANSMI TTED_0UTPUT_INH1BI TS 

RECEI VED_S I GN A L_SOURC ES 

SIGNAL I NG_MODE 

RECE I VED_S I GNAL_LEVEL_REPORT I NG 
LAN_T OPOLOGY_TYPE 
TS 


[0] VA LUE_ I NT EGER_ 1 

[1] VALUE_INTEGER_1 

[2] VALUE, 1NTEGER_1 

[3] VALUE_INTEGER_1 

[4] VALUE, 1NTEGER_1 

[5] VALUE_INTEGER_1 

[6] VALUE_INTEGER_1 

[7] VALUE, INTEGER, 1 

[8] VALUE, I NT EGER, 1 

[9] VALUE,] NTEGER.1 

[10] VALUE_INTEGER_1 

[11] VALUE_INTEGER_1 

[12] VALUE_INTEGER_1 

[13] VALUE_INTEGER_1 

[14] VALUE_INTEGER_1 

[15] VALUE_INTEGER_1 

[16] VALUE_INTEGER_1 

[17] VALUE_INTEGER_1 

[18] VALUE_INTEGER_1 

[19] VALUE_INTEGER_1 

[20] VALUE_INTEGER_1 

[21] VALUE_I NTEGER_1 

[22] VALUE_INTEGER_1 


\ 
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TS VALUE.ADDRESS.1 

NS : •.= VALUE_ADDRESS_1 

SLOT_T IME : := VALUE_INTECER_1 

H!_PRI_TOKEN_HOLD_TIME : := VALUE_ INTEGER, 1 

MAX_AC_4_R0T AT I ON.T I ME : := VALUE_INTEGER_1 

MAX_AC_2_ROT ATI ON_T IME : VALUE_INTEGER_1 

MAX_AC_0_ROT AT 1 ON_T I ME : := VALUE_INTEGER_1 

MAC_R I NG_MA I NT ENANC E_ROT AT 10N_TIME ::= VALUE_INTEGER_1 

R I NG_MA I NT ENANC E_T 1 MER_ I N I T I A L_VA LU E : := VALUE_1NTEGER_1 

MAX_ I NTER_SOL I C I T_COUNT : := VALUE_INTEGER_1 

MIN.POST.SILENCE.PREAMBLE.LENGTH : VALUE_]NTEGER_1 

I N_R I NG.D ES I R ED : VALUE_INTEGER_1 

EVENT_ENABLE_MASK : := EVENT_ENABLE_BITS 

MAX_RETRY_LIM1 T : := VALUE.INTEGER.1 

MA_GROUP_ADOR ESS : = VALUE.ADDRESS.1 

MA_GROUP_ ADDRESS. ALL : VALUE.ADDRESS.1 6 

CHANNEL.ASS I GNMENT S : VALUE_INTEGER_1 

TRANSM I TT ED_POWER_ LEVEL. AD JUSTMENT : := VA LUE_ I NT EGER_ 1 

TRANSMI TT£D_OUTPUT_ INHIBITS : := VALUE_INTEGER_1 

RECE I VED_S1 GNAI SOURCES : :* VALUE. INTEGER. 1 

SIGNALING.MODE : := VALUE.INTEGER.1 

RECE I VED.S I GNAI LEVEL.REPORT I NG : VALUE.INTEGER.1 

LAN.TOPOLOGY.TYPE : := VALUE.INTEGER.1 
FREEZE.MAC ::= VALUE.INTEGER.1 


MAC.TYPE 04h 


TOKEN/STAR BUS MAC SOFTWARE USERS DOCUMENT 
INTERFACES 


Page 54 
20 July 1987 


STATUS.TYPE : _ CHOICE 


UNDEF I NED__ERROR 

to] 

VALUE_1NTEGER_1 

SUCCESS 

[i] 

VALUE_INTEGER_1 

REFUSE_TO_COMPLY 

[2] 

VALUE. I NT EGER. 1 

NONSUPPORTED 

[3] 

VALUE. INTEGER. 1 

ERROR_IN_PREFOR 

M 

VALUE. I NT EGER.1 

NOT_AVAI LABLE 

[5] 

VA LU E. I NT EG ER. 1 

B AD_P AR AMET ER_ 1 D 

[6] 

VALUE. INTEGER.1 

BAD_P ARAMET ER_OP ER ERAT I ON 

[7] 

VALUE.INTEGER.1 

B AD_P AR AMET ER_VA LU E 

[8] 

VALUE. I NT EGER.1 

BAD_EXPECTED_VALUE 

[9] 

VALUE. INTEGER.1 


EVENT_TYPES ::= IMPLICIT SEQUENCE 
J EVENT.CLASS EVENT_CLASS_TYPES } 

EVENT_C LASS_TYPES : := CHOICE 

{ LOCAL [0] EVENT_ I DENT 1 F I ER_TYPES | 

REMOTE [1] EVENT. I DENT I F 1 ER_TYPES \ 


EVENT. I DENT 1 F 1 ER_TYPES 


CHOICE 


NS.CHANGED 

[0] 

VALUE. INTEGER.1 

NS.NULL 

[1] 

VALUE. INTEGER.1 

DUP L I CAT E.ADDRESS 

[2] 

VALUE.INTEGER.1 

FAULTY.TRANSMI TTER 

[3] 

VALUE. INTEGER.1 

XMIT.OUEUE.THRESHOLD. EXCEEDED 

[4] 

VALUE.INTEGER.1 

RECE I VE.QUEUE.THRESHOLD. EXCEEDED 

[5] 

VALUE.INTEGER.1 

WATCH.DOG.TIMEOUT 

[6] 

VALUE.INTEGER.1 

FROZEN 

[7] 

VALUE.INTEGER.1 

TOKEN. LOST 

[8] 

VALUE.INTEGER.1 

DUAL.TOKEN 

[9] 

VALUE.INTEGER.1 

MAX.RETRY.ENCOUNTERED 

[10] 

VALUE.INTEGER.1 

BAD.MESSAGE.SENT 

[11] 

VALUE.ADDRESS.1 

VENT.ENABLE.BITS ::= BIT STRING 

NS.CHANGED 

(0). 


NS.NULL— 

(D. 


DUPLICATE. ADDRESS 

(2). 

- 

F AU LTY.T&ANSM I TT ER 

(3). 


XMI T.OUEUE.THRESHOLD.EXCEEDED 

(4). 


RECEIVE.OUEUE.THRESHOLD. EXCEEDED 

(5). 


WATCH.DOG.TIMEOUT 

(6). 


FROZEN 

(7). 


TOKEN. LOST 

(8). 


DUAL.TOKEN 

(9). 


MAX.RETRY.ENCOUNTERED 

(10) 


BAD.MESSAGE.SENT 

(11) 

t 


— Where 1 is enabled 


